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Abstract 

Distributed-memory  programs  are  often  written  using  a  global  address  space:  any  process  can  name 
any  memory  location  on  any  processor.  Some  languages  completely  hide  the  distinction  between  local 
and  remote  memory,  simplifying  the  programming  model  at  some  performance  cost.  Other  languages 
give  the  programmer  more  explicit  control,  offering  better  potential  performance  but  sacrificing  both 
soundness  and  ease  of  use. 

Through  a  series  of  progressively  richer  type  systems,  we  formalize  the  complex  issues  surrounding 
sound  computation  with  explicitly  distributed  data  structures.  We  then  illustrate  how  type  inference 
can  subsume  much  of  this  complexity,  letting  programmers  work  at  whatever  level  of  detail  is  needed. 
Experiments  conducted  with  the  Titanium  programming  language  show  that  this  can  result  in  easier 
development  and  significant  performance  improvements  over  manual  optimization  of  local  and  global 
memory. 


1  Introduction 

While  there  have  been  many  efforts  to  design  distributed,  parallel  programming  languages,  none  has  been 
completely  satisfactory.  Many  approaches  present  the  illusion  of  a  single  shared,  global  address  space.  While 
easy  for  programmers  to  understand,  this  approach  hides  the  real  structure  of  memory,  making  it  difficult  to 
exploit  locality  of  data.  In  complex  applications  where  local  memory  accesses  may  be  orders  of  magnitude 
faster  than  remote  accesses,  this  can  seriously  harm  performance,  development  time,  or  both. 

Another  approach  is  to  reveal  the  full  distributed  memory  hierarchy  at  the  language  level.  A  popular 
model  is  to  allow  a  mixture  of  global  and  local  pointers:  the  former  span  the  entire  global  address  space,  while 
the  latter  only  address  memory  that  is  physically  colocated  with  a  given  processor.  This  supports  globally 
shared  data  structures  while  still  allowing  efficient  implementation  of  algorithms  specifically  structured  for 
distributed  OOparallel  execution  [4,5,7,8,11,17,  et  al). 

Historically,  programming  languages  that  expose  mutable  local  and  global  addresses  have  been  unsound. 
Designing  a  sound  type  system  which  allows  local  and  global  pointers  turns  out  to  be  a  subtle  problem. 
Exposing  local/global  also  places  an  additional  burden  on  the  programmer,  who  may  be  forced  to  attend  to 
the  details  of  memory  layout  even  in  sections  of  code  that  are  not  performance  critical. 

This  paper  makes  three  principal  contributions: 

•  Through  a  progression  of  sound  type  systems,  we  illustrate  and  clarify  the  semantic  issues  surrounding 
local  and  global  pointers. 

•  We  present  a  type  inference  system  that  is  capable  of  completing  a  program  with  inferred  local/global 
annotations,  thereby  relieving  the  programmer  from  managing  address  spaces  in  much  or  all  of  the 
code. 

*This  research  was  supported  in  part  by  NASA  Grant  No.  NAG2-1210,  Defense  Advanced  Research  Projects  Agency  contract 
No.  F30602-95-C-0136,  National  Science  Foundation  Infrastructure  Grant  Nos.  CDA-9401156  and  EIA-9802069,  and  an  NDSEG 
fellowship.  The  information  presented  here  does  not  necessarily  reflect  the  position  or  the  policy  of  the  Government  and  no 
official  endorsement  should  be  inferred. 
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if  (p. processor  ==  MyProcessor) 
result  =  *p. address; 

else 

result  =  RemoteRead(p. processor ,  p. address); 

Figure  1;  Dereferencing  a  global  pointer.  Because  “result'’  may  receive  its  value  from  an  opaque 
function  call,  the  compiler  is  unlikely  to  be  able  to  effectively  optimize  any  code  that  uses  the  resulting  value. 


•  We  present  experimental  results  showing  that  this  inference  algorithm  improves  program  performance 
significantly,  simplifies  development,  and  does  a  better  job  than  hand-optimization  by  humans. 

The  remainder  of  this  paper  is  structured  as  follows.  Section  2  offers  a  primer  on  the  common  termi¬ 
nology  with  which  we  discuss  distributed  address  spaces  and  highlights  some  of  the  performance  costs  of 
simpler  models  that  treat  distributed  memory  as  though  it  were  shared  memory.  In  Section  3  we  develop 
a  series  of  small  languages  and  type  systems  that  codify  sound  computing  with  distributed  mutable  data 
structures.  The  more  expressive  systems  are  also  more  complex;  Section  4  shows  how  type  inference  can 
simplify  programming  while  retaining  the  full  power  of  the  type  system.  We  have  applied  these  principles 
to  the  Titanium  programming  language,  and  report  the  results  of  our  experiments  in  Section  5.  Section  6 
reviews  related  work.  We  conclude  in  Section  7  by  summarizing  our  findings,  and  discussing  directions  for 
future  research. 


2  Background 

When  describing  interconnections  between  allocated  blocks  of  data,  we  use  the  term  pointer,  which  reinforces 
the  idea  that  we  are  discussing  very  low  level  operations.  Although  pointers  can  implement  Standard  ML 
ref’s  [24]  or  Java  references  [16],  pointers  are  more  primitive. 

Our  distributed  memory  model  is  an  explicit  two-level  hierarchy  with  local  and  global  memory.  Local 
memory  is  physically  colocated  with  a  processor.  A  system  with  sixteen  processors  has  sixteen  distinct  local 
memories.  A  local  pointer  encodes  an  address  within  one  local  memory  and  corresponds  to  a  pointer  or 
memory  address  in  standard  languages.  Local  pointers  do  not  travel  well;  a  local  address  formed  on  one 
processor  is  meaningless  elsewhere. 

Global  memory  is  the  union  of  all  local  memories.  If  we  assume  that  processors  are  uniquely  numbered, 
then  a  global  pointer  encodes  a  pair  ( processor ,  address) ,  with  a  home  processor  and  an  address  within  that 
processor’s  local  memory.  Global  pointers  have  a  different  representation  from  local  pointers  and  are  more 
costly  to  use.  Manipulating  remote  memory  may  involve  special  machine  instructions,  trapping  into  the 
operating  system,  or  function  calls  into  a  message-passing  library.  The  exact  mechanism  is  irrelevant.  What 
matters  is  that  global  and  local  pointers  have  different  representations  and  are  manipulated  using  different 
operations. 

While  dereferencing  a  global  pointer  to  another  processor’s  memory  can  be  extremely  slow,  even  a  global 
pointer  into  local  memory  generally  incurs  a  performance  penalty.  As  Figure  1  illustrates,  dereferencing  a 
global  pointer  that  turns  out  to  be  local  may  entail  comparing  two  values,  ignoring  a  branch  to  the  remote 
fetch  clause,  dereferencing  the  local  address,  and  branching  to  the  end  of  the  entire  conditional.  The  presence 
of  a  branch,  combined  with  the  possibility  of  a  function  call,  may  make  it  difficult  for  an  optimizing  compiler 
to  improve  code  using  the  result  of  a  statically  global  dereference. 

Benchmarking  quantifies  these  concerns.  A  Split-C  [1-J]  benchmark  was  run  using  various  strategies  to 
implement  global  pointers.  The  benchmark,  EM3D,  repeatedly  walks  across  an  irregular  bipartite  graph 
performing  a  simple  calculation.  We  can  estimate  the  cost  of  global  pointers  to  local  data  by  computing  the 
average  time  required  per  edge  when  all  data  is  stored  locally.  Table  1  shows  times  collected  on  a  Thinking 
Machines  CM-5  and  partial  times  collected  on  a  Cray  T3D.  These  findings  were  originally  presented  in  [22] 
and  [29],  respectively. 

The  benchmark  reveals  that  the  performance  cost  of  using  global  pointers  for  local  data  is  significant. 
Even  when  the  code  for  reading  and  writing  through  global  pointers  references  is  inlined,  the  CM-5  shows 
nearly  a  75%  slowdown  compared  with  simple  pointers.  This  is  largely  due  to  lost  opportunities  for  opti- 
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CM-5 

T3D 

function 

2.8  /rsec/edge 

1.19 

inline 

2.0 

0.71 

optimized 

1.3 

0.66 

narrow 

1.15 

N/A 

Table  1:  Costs  of  global  pointers  to  local  data.  ‘‘Function”  uses  global  pointers  and  requires  a  function 
call  for  every  read  or  write.  ‘‘Inline”  inlines  global  pointer  code  directly  at  the  point  of  use.  ‘‘Optimized” 
uses  extensive  manual  optimization  and  likely  represents  the  theoretical  best  performance  possible  for  global 
references.  “Narrow”  uses  simple  pointers,  and  represents  a  level  of  performance  only  possible  with  true, 
physically  shared  memory. 


mization.  Extensive  manual  optimization  included  relocating  code  into  the  “local”  clause  of  the  locality  test 
to  avoid  a  branch.  Such  heroic  efforts  bring  performance  to  within  13%  of  simple  pointers;  the  difference  is 
probably  due  to  less  effective  register  use  and  the  increased  time  to  move  larger  amounts  of  data  around  in 
memory. 

Thus,  high  performance  parallel  code  must  acknowledge  the  distributed  nature  of  memory.  Where  data 
structures  genuinely  span  processor  boundaries,  global  pointers  are  entirely  appropriate.  But  when  static 
information  can  prove  that  data  is  always  local,  global  pointers  are  needlessly  costly. 

3  A  Progression  of  Type  Systems 

We  present  a  suite  of  three  languages  and  type  systems  that  offer  both  global  and  local  pointers,  illustrating 
the  key  soundness  issues  that  arise  when  manipulating  distributed  data  structures.  All  three  systems  have 
been  reduced  to  essentials  to  more  clearly  illuminate  the  novel  issues.  These  are  not  languages  in  which 
one  would  program  directly.  Rather,  these  languages  should  be  considered  as  just  barely  above  the  level  of 
primitive  machine  addressing. 

Our  foremost  concern  is  distributed  data,  not  mobile  code.  Therefore,  none  of  the  languages  we  describe 
contains  A  expressions,  let  bindings  or  any  other  facility  for  introducing  new  functions,  variables,  or  closures. 
Rather,  we  assume  a  fixed  set  of  named  functions  and  variables  available  in  an  initial  environment.  Functions 
are  not  first-class;  function  types  are  not  data  types,  and  function  names  only  appear  directly  applied  to 
arguments.  In  Section  7  we  briefly  consider  extensions  allowing  first-class  functions;  for  now,  we  focus  on 
data. 

Similarly,  we  omit  the  details  of  a  parallel  semantics.  A  single  language  construct,  the  unary  transmission 
operator,  represents  an  explicit  transfer  of  information  from  one  processor  to  another.  An  expression  of  the 
form  “transmit  e”  should  be  read  as  evaluating  expression  “e”  on  one  processor,  then  transmitting  the  result 
to  a  different  processor.  The  result  of  a  transmit  expression  is  the  value  as  seen  on  the  receiving  processor. 
This  is  the  only  explicit  communication  primitive;  all  other  data  is  exchanged  implicitly,  via  global  pointers. 
The  presentation  here  is  deliberately  somewhat  informal.  An  operational  semantics  and  soundness  proof  for 
the  most  complex  type  system  are  presented  in  the  appendix. 

The  first  language  contains  local  and  global  pointers  with  arbitrary  levels  of  indirection  but  without 
updates.  The  second  language  introduces  an  assignment  operator  for  destructive  updates.  The  third  language 
adds  pairs  with  updatable  fields,  which  model  the  composite  records,  objects,  or  data  structures  of  higher 
level  languages. 

3.1  System  I:  Simple  Pointers 

Our  first  language  contains  integers,  local  and  global  pointers,  and  basic  pointer  operations.  It  has  neither 
destructive  assignment  nor  compound  data  types;  these  are  added  in  sections  3.2  and  3.3,  respectively. 
Expression  and  type  grammars  are  given  in  Figure  2.  Figure  3  gives  type  checking  rules.  A  type  environment, 
A,  encapsulates  information  about  externally  defined  variable  and  function  names. 

To  discuss  pointers  and  pointer  operations,  we  work  with  boxed  and  unboxed  values.  As  is  standard, 
types  represent  unboxed  values  unless  explicitly  boxed.  One  may  take  a  value’s  address  using  the 
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J  ::=  integer  literals 

e  ::=  J|:r|/e|'|"e|,[.e|  widen  e  |  transmit  e 

r  ::=  int  |  boxed  u>  t 
lo  ::=  local  |  global 


Figure  2:  Expressions  and  types  I.  Expressions  are  given  by  e,  while  r  represents  expression  types. 


indirection  operator,  so  while  “5”  is  a  pattern  of  bits  representing  five,  “f  5”  is  a  local  pointer  to  a  memory 
location  holding  the  value  five.  We  use  “boxed”  to  describe  pointer  types,  augmented  with  a  width  qualifier 
to  distinguish  global  from  local  pointers.  The  “widen”  operator  widens  a  local  pointer  to  global.  Hence: 


5 
T5 
T  T  5 

widen  f | 5 


int 

boxed  local  int 

boxed  local  boxed  local  int 

boxed  global  boxed  local  int 


The  “J.”  dereferencing  operator  retrieves  the  value  addressed  by  a  pointer.  Dereferencing  a  local  pointer 
works  as  expected,  essentially  stripping  off  an  outer  level  of  boxing.  Dereferencing  a  global  pointer  is  more 
subtle. 


3.1.1  Implicit  Type  Expansion 

The  difficulty  with  global  pointer  dereferencing  is  illustrated  in  Figure  4.  Dotted  lines  mark  local  memory 
boundaries;  in  this  case,  we  have  two  processors  and  therefore  two  local  memories.  Processor  1  has  con¬ 
structed  a  local  pointer  to  a  memory  location  storing  the  value  five.  We  indicate  local  pointers  using  a  single 
arrow.  Processor  0  has  a  variable  x  of  type  boxed  global  boxed  local  int:  a  global  pointer  to  a  local 
pointer  to  an  integer.  We  use  double  arrows  to  indicate  global  pointers.  A  naive  dereference  of  x  would 
simply  extract  the  local  pointer  value  f  5.  However,  that  local  pointer  is  meaningless  in  processor  0’s  local 
address  space.  Rather,  as  the  figure  suggests,  the  local  pointer  addressed  by  x  must  be  widened,  so  that  J,  x 
is  global  as  well.  The  new  global  pointer’s  home  processor  is  1,  while  its  address  on  processor  1  is  the  same 
as  the  address  expressed  by  f  5. 

Widening  is  only  needed  when  an  operation  could  cause  the  value  of  a  local  pointer  to  cross  processor 
boundaries.  Thus,  if  y  :  boxed  global  int  is  a  global  pointer  to  an  integer,  then  J,  y  :  int  is  the  value  of  that 
integer.  Similarly,  if  z  :  boxed  global  boxed  global  int  is  a  global  pointer  to  a  global  pointer  to  an  integer, 
then  |  z  :  boxed  global  int  would  traverse  one  level  of  indirection,  yielding  a  global  pointer  to  an  integer. 
Widening  is  required  when  transmitting  a  local  pointer:  if  f  5  has  type  boxed  local  int,  then  transmit  |  5 
must  have  type  boxed  global  int,  or  else  the  receiving  processor  would  be  left  holding  a  local  pointer  into 
the  wrong  address  space.  But  transmit  5  requires  no  special  manipulation,  because  integers  travel  safely 
across  processor  boundaries. 

The  expand  function,  used  in  the  final  two  type  rules,  is  given  in  Figure  5.  It  widens  local  pointers  to 
global,  but  leaves  other  types  unchanged.  Simple  though  this  may  seem,  real  parallel  programming  languages 
do  not  necessarily  get  this  right.  Split-C,  for  example,  makes  no  effort  to  prevent  processors  from  seeing  each 
other’s  local  pointers.  In  cases  like  Figure  4,  the  programmer  is  expected  to  extract  the  processor  number 
from  x  and  manually  combine  that  with  the  local  pointer  at  J.  x  to  produce  a  valid  global  pointer.  Forgetting 
to  do  so  elicits  no  warning  from  the  compiler;  the  program  simply  contains  a  wild  pointer  [13]. 

3.2  System  II:  Assignable  Pointers 

We  now  extend  the  language  with  destructive  assignment  through  pointers.  An  updated  grammar  appears 
in  Figure  6.  To  help  support  assignment  we  have  also  added  sequencing. 
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A(x)  =  r 

A  b  J  :  int  A  b  x  :  r 

A(/)  =  r  — >  r'  A  b  e  :  r 
A  b  /  e  :  t' 

A  h  e  :  t 

A  b  |  e  :  boxed  local  r 

.Abe:  boxed  local  r 

A  b  J.  e  :  t 

Abe:  boxed  global  r 

A  b  |e  :  expander) 

Abe:  boxed  local  r 
A  b  widen  e  :  boxed  global  r 

A  b  e  :  t 

A  b  transmit  e  :  expander) 
Figure  3:  Type  checking  rules  I. 


processor  0 

processor  1 

X  ^ 

r-*l 

|5 

la: 

n 

Figure  4:  Situation  requiring  type  expansion. 


expand( boxed  local  r)  =  boxed  global  r 
expander)  =  t  otherwise 

Figure  5:  Type  manipulating  functions  I. 
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J  ::=  integer  literals 

e  ::=  J|a;|/e|fe|J,e|  widen  e  |  transmit  e  | 

e  ;  e  |  e  :  =  e 

r  ::=  int  |  boxed  uj  t 
uj  ::=  local  |  global 

Figure  6:  Expressions  and  types  II.  Relative  to  Figure  2,  expressions  now  allow  sequencing  ( ; )  and 
assignment  (:=)■ 

Given  a  pointer  to  some  memory  location  and  a  compatible  value,  the  new  “ :  =”  assignment  operator 
writes  a  new  value  into  the  pointed-to  location,  replacing  what  may  have  been  stored  there  before.  The 
pointer  itself  is  unchanged;  it  merely  identifies  the  target  of  the  store  operation.  This  is  a  more  primitive 
operation  than,  for  example,  assignment  to  an  ML  ref,  although  ML  assignment  could  be  implemented  using 
our  primitive  plus  an  extra  level  of  indirection.  The  key  point  is  that  the  left  hand  side  of  an  assignment 
must  always  be  a  pointer,  and  that  the  new  value  is  placed  in  the  location  to  which  the  pointer  refers. 

3.2.1  Type  Expansion  Versus  Assignment 

Type  checking  rules  for  the  augmented  language  are  given  in  Figure  7.  As  before,  the  interesting  case  is 
a  global  pointer  to  local  pointer,  such  as  x  in  Figure  8.  Suppose  that  global  pointer  x  is  to  receive  an 
assignment,  via  “x  :  =  |  6”.  The  types  seem,  superficially,  to  match:  x  addresses  a  local  pointer  to  int,  and 
1 6  is  also  a  local  pointer  to  int.  Yet  that  local  pointer  would  be  meaningless  if  transported  from  processor 
0  across  to  processor  1.  Widening  j  6  to  global  is  no  solution  either,  because  the  box  to  which  x  points  is 
typed  as  local. 

In  general,  then,  we  must  forbid  assignment  to  local  pointers  across  globals.  The  local  pointer  value  can 
be  read,  subject  to  expansion  as  seen  earlier.  But  it  can  never  be  updated.  The  core  issue  is  that  local 
pointers  cannot  travel  across  processor  boundaries,  and  global  pointers  use  a  different  and  incompatible 
representation.  Figure  9  gives  the  robust  predicate  that  enforces  these  restrictions.  A  robust  type  is  one  that 
can  safely  travel  across  a  global  pointer  during  an  assignment.  Note  that  assignment  across  local  pointers 
requires  no  such  test,  as  it  is  always  safe  providing  the  source  and  destination  types  match. 

3.3  System  III:  Assignable  Tuples 

Lastly,  we  enrich  the  language  with  tuples.  For  simplicity,  we  only  permit  pairs;  general  n-tuples  contribute 
nothing  novel.  The  language  and  type  grammars  appear  in  Figure  10.  We  have  added  a  pair  constructor 
(_,  _},  plus  two  new  operators  for  decomposing  pairs. 

Given  a  valid  pointer  to  a  pair,  the  @1  and  @2  pair  selection  operators  produce  offset  pointers  to  the  first 
and  second  components  of  the  pair.  Again,  this  is  more  primitive  than  the  #n  record  selection  operator  from 
ML,  and  the  two  should  not  be  confused.  Assuming  that  ML  records  are  always  boxed,  ML  record  selection 
roughly  corresponds  to  pair  selection  followed  by  dereference  (|@n).  Primitive  pair  selection  alone,  without 
dereference,  forms  a  pointer  suitable  for  assignment,  permitting  in-place  mutation  of  one  component  of  a 
pair  while  leaving  the  other  unchanged.  The  need  for  these  atypical  operators  will  become  more  evident  in 
Section  3.3.2. 

We  have  also  added  a  subtyping  relation,  defined  in  Figure  11.  The  subtyping  relation  allows  one  to 
weaken  pointer  types  by  promoting  certain  p  qualifiers  from  valid  to  invalid.  This  qualifier  subsumption 
is  allowed  at  the  top  level  or  embedded  anywhere  within  a  top  level  pair.  However,  one  cannot  change 
validity  qualifiers  below  a  pointer.  If  this  were  permitted,  then  it  would  be  possible  for  two  pointers  with 
different  types  to  alias  the  same  value,  which  is  unsound  in  the  presence  of  assignment.  No  implicit  changes 
to  the  uj  qualifier  are  permitted  at  all,  because  this  entails  a  change  of  representation,  and  therefore  should 
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A(x)  =  t 
A  h  x  :  t 


A  h  J  :  int 


A(f)  =  r  —>  t'  A  b  e  :  r 
A  b  /  e  :  t' 

A  \-  e  :  t 

A  b  | e  :  boxed  local  r 

A  be:  boxed  local  r 
A  b  l  e  :  t 

A  he:  boxed  global  r 

A  h  l  e  :  expander) 

A  he:  boxed  local  r 
A  h  widen  e  :  boxed  global  r 

A  h  e  :  r 

A  h  transmit  e  :  expand(r) 


A  b  e  :  r  A  b  e'  :  t' 

A  h  e  ;  e!  :  r' 

A  h  e  :  boxed  local  r  ^4  h  e'  :  r 
^4  h  e  e'  :  r 

A  h  e  :  boxed  global  r  A  h  e'  :  r  robust{r) 

A  b  e  e'  :  r 

Figure  7:  Type  checking  rules  II.  Rules  above  the  dotted  line  are  identical  to  those  in  Figure  3,  while 
those  below  the  line  are  new. 
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Figure  8:  Situation  precluding  assignment. 
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expand( boxed  local  r)  =  boxed  global  r 
expander)  =  t  otherwise 

robustpoxed  local  r)  =  false 

robustp )  =  true  otherwise 

Figure  9:  Type  manipulating  functions  II.  The  expand  function  is  unchanged  from  Figure  5.  The  robust 
predicate  is  new. 


J  ::=  integer  literals 

e  ::=  J|x|/ejte||e|  widen  e  |  transmit  e  j 
e  ;  e  |  e  :  =  e  |  (e,  e)  |  @1  e  |  @2  e 
r  ::=  int  |  boxed  u>  p  r  |  (r,  r) 
u)  ::=  local  |  global 
p  ::=  valid  |  invalid 

Figure  10:  Expressions  and  types  III.  Relative  to  Figure  6,  expressions  now  allow  pair  creation  ((-,-)) 
and  selection  ( @n ).  Types  include  pairs,  and  the  pointer  types  now  carry  an  additional  validity  qualifier  p. 


logically  produce  a  new  value. 

3.3.1  Consistent  Representation  of  Pairs 

As  we  have  seen,  when  an  isolated  local  pointer  moves  across  processor  boundaries,  it  must  be  expanded 
into  a  global  pointer.  What  about  moving  an  unboxed  pair  containing  a  local  pointer?  One  option  would 
be  to  expand  the  embedded  pointer  as  before.  Thus,  expand(( boxed  local  r,  int))  could  be  defined  as 
(boxed  global  t,  int).  However,  this  means  that  the  expanded  pair  would  have  a  different  representation 
than  the  original  pair.  This  approach  is  very  unattractive  in  any  language  with  named  record  types  (i.e., 
almost  all  languages).  Suppose  the  programmer  declares  Entry  as  a  pair  (boxed  local  r  ,  int)  for  some  r. 
What  name  would  we  use  for  the  expanded  pair?  Entry  is  inappropriate,  since  the  type  has  changed.  Do  we 
synthesize  a  new  name?  Assume  that  the  value  belongs  to  some  anonymous  record  type?  Any  functions  that 
manipulate  unboxed  Entry  values  cannot  properly  use  the  expanded  pair,  because  its  representation  (and 
possibly  size  and  component  offsets)  will  have  changed.  Treating  Entry  as  polymorphic  in  its  to  qualifiers 
would  entail  either  generating  multiple  copies  of  code,  or  else  inserting  runtime  tests  wherever  polymorphic 
pointers  are  used.  But  code  expansion  is  undesirable  and  runtime  pointer  tests  are  exactly  what  we  wish  to 
avoid. 

Thus,  we  wish  to  ensure  that  expand  never  causes  a  pair  to  change  representation.  Local  pointers  within 
pairs  should  remain  local,  even  when  copied  between  processors.  Such  pointers  no  longer  represent  valid 
memory  addresses  and  must  never  subsequently  be  used.  We  add  a  new  validity  qualifier ,  p ,  to  mark  when 
an  embedded  local  pointer  has  been  invalidated  by  movement  between  processors.  Thus,  when  an  unboxed 
Entry  is  moved  across  processor  boundaries,  its  embedded  local  pointer  is  marked  as  invalid.  But  the 
second  component  of  the  tuple,  an  embedded  integer,  remains  accessible.  An  embedded  global  pointer 
would  likewise  arrive  unscathed.  Any  existing  function  that  manipulates  unboxed  Entry  values  could  still 
be  used,  provided  that  it  only  accesses  the  integer,  and  never  touches  the  (now  invalid)  local  pointer. 

Figure  12  presents  our  final  set  of  type  checking  rules.  The  updated  expand  and  robust  functions  in 
Figure  13  complete  the  picture.  A  new  function,  pop ,  is  responsible  for  traversing  pairs  and  invalidating  any 


p  <  p  valid  <  invalid  r  <  r 

boxed  u>  p  t  <  boxed  u>  p'  r  •<=>•  p  <  p' 

(n,  r2)  <  {t[ ,  t'2)  <=>  n  <  A  r2  <  t'2 


Figure  11:  Subtyping  relation  for  type  system  III. 


embedded  local  pointers.  The  robust  predicate,  which  forbids  unsound  assignments  across  global  pointers, 
has  been  relaxed  slightly.  Cross-global  assignments  to  valid  local  pointers  are  forbidden.  But  cross-global 
assignments  to  invalid  local  pointers  are  allowed:  if  a  local  pointer  is  already  invalid  on  the  receiving  end, 
one  can  certainly  replace  it  with  a  different  invalid  local  pointer.  The  robust  and  pop  functions  have  an 
important  relationship:  robust(r)  is  true  if  and  only  if  pop(r)  =  r.  Intuitively,  a  value  can  be  assigned  across 
a  global  pointer  if  and  only  if  it  will  not  be  damaged  in  transit. 

3.3.2  Selection  Without  Dereference 

We  can  now  demonstrate  why  it  is  important  to  have  pair  selection  operators  that  do  not  also  immediately 
dereference.  Suppose  that  we  are  given  a  global  pointer  to  (4,  (x,  5)),  where  x  is  some  embedded  local  pointer. 
We  wish  to  extract  x.  If  selection  is  always  coupled  with  dereference,  then  selecting  the  second  component 
of  the  pair  would  produce  the  unboxed  value  (x,  5).  There  is  no  global  pointer  associated  with  this  value; 
we  have  carried  the  local  pointer  x  across  processors,  and  can  no  longer  safely  use  it.  Therefore,  the  expand 
and  pop  functions  will  have  correctly  marked  x  as  invalid. 

However,  if  selection  and  dereferencing  are  distinct  operations,  we  can  do  better.  Given  a  global  pointer 
to  (4,  (x,  5)),  selecting  the  second  component  will  produce  a  global  pointer  to  (x,  5).  Selecting  the  first 
component  of  this  yields  a  global  pointer  to  x.  We  already  know  how  to  use  global  pointers  to  local  pointers: 
dereferencing  yields  a  valid  global  pointer  equivalent  to  widen  x. 

Thus,  we  find  that  a  sequence  of  selection  operations  must  not  dereference  too  early.  Selection  should 
be  treated  as  simple  pointer  displacement.  When  extracting  a  value  deeply  embedded  in  nested  pairs,  all 
selection  displacements  must  be  applied  first,  and  only  then  should  the  final  offset  pointer  be  dereferenced. 

4  From  Checking  to  Inference 

The  third  system  provides  address  space  management,  safe  pointers,  and  updatable  tuples.  This  forms 
a  suitable  starting  point  for  the  design  of  a  realistic  language  for  manipulating  distributed  mutable  data 
structures.  However,  it  is  impractical  to  expect  programmers  to  systematically  annotate  programs  with 
local,  global,  valid,  and  invalid  type  qualifiers;  it  is  simply  too  cumbersome  and  time  consuming  (see 
Section  5.1). 

Fortunately,  the  type  qualifiers  we  have  described  are  quite  amenable  to  automatic  inference.  Figure  14 
shows  a  set  of  inference  rules  directly  derived  from  the  third  type  system.  One  new  rule  allows  implicit 
coercion  of  pointers  from  local  to  global.  This  is  allowed  at  the  top  level  only,  both  to  keep  pair  types 
consistent  as  well  as  to  avoid  the  well-known  soundness  problems  in  allowing  distinct  aliases  of  mutable  data 
to  have  different  types.  For  clarity  of  presentation,  the  rules  use  several  abbreviations: 

1.  Constraints  are  not  explicitly  propagated  up  from  subexpressions;  assume  that  the  complete  constraint 
set  is  the  simple  union  of  the  sets  of  constraints  induced  by  all  subexpressions. 

2.  A  nontrivial  rule  hypothesis  such  as 


e  :  boxed  u>  valid  r 

should  be  read  as  an  equality  constraint 

e  :  tq  tq  =  boxed  u>  valid  r 
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A(x)  =  T 

A  b  J  :  int  A  b  x  :  r 

A(f)  =  t  — >  t'  A  h  e  :  t 

A  h  f  e  :  t' 

A  h  e  :  t 

A  b  | e  :  boxed  local  valid  r 

A  be:  boxed  local  valid  r 

A  b  [e  :  r 

4  h  e  :  boxed  global  valid  r 

4  h  |e  :  expander) 

A  h  e  :  r 

A  h  transmit  e  :  expand(r) 

A  h  e  :  t  A  h  e'  :  t' 

A  b  e  ;  e!  :  t’ 


A  he:  boxed  local  valid  r  A  h  e7  :  r 
^4  h  e  :  =  e7  :  r 


4  h  e  :  boxed  global  valid  r 

A  h  e!  :  r  robust(r) 

A  b  e  :  =  e'  :  r 


4  h  ei  :  Ti  4  h  e2  :  T2 
A  b  (ei,e2)  :  (ri,r2) 

4  b  e  :  boxed  w  valid  (ti,T2) 
4  b  ®ne  :  boxed  a;  valid  rn 


A  b  e  :  r  t  <  t' 

A  b  e  :  t' 

Figure  12:  Type  checking  rules  III.  Rules  above  the  dotted  line  are  identical  to  those  in  Figure  7,  or  have 
been  changed  trivially  to  support  the  p  qualifier.  Rules  below  the  line  are  new. 
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expand(boxed  local  p  r) 
expand{{r\,T2j) 
expander) 

pop(boxed  local  p  r)  = 
pop((T1,T2))  = 

pop{r)  = 

robust( boxed  local  valid  r) 
robust((ri ,  r2)) 
robust(r) 


=  boxed  global  p  r 

-  ( pop{Ti),pop{T2 )) 

=  t  otherwise 

boxed  local  invalid  r 

(. Pop{Ti),pop{T2 )) 
t  otherwise 

=  false 

=  robust(ri )  A  robust (r2) 
=  true  otherwise 


Figure  13:  Type  manipulating  functions  III. 


3.  All  constraint  variables  are  fresh. 

The  inference  rules  induce  a  set  of  constraints  on  unknown  qualifiers;  for  example,  the  operand  of  any 
dereference  operator  is  constrained  to  be  qualified  as  valid.  Figure  15  shows  supporting  functions  that 
generate  additional  constraints.  Type  qualifier  inference  requires  finding  a  solution  to  the  set  of  all  constraints 
induced  by  a  program. 

Some  constraints  generated  by  the  pop  and  robust  functions  have  the  following  general  form: 

to*  =  global  =>  ( u  =  global  V  p  =  invalid) 

These  conditional  constraints  arise  whenever  data  crosses  a  (possibly  global)  pointer.  For  example,  when 
dereferencing  a  pointer  to  a  pair,  if  the  pointer  being  dereferenced  is  global  (w*  =  global),  then  either  a 
pointer  embedded  in  the  pair  must  also  be  global  (w  =  global)  or  else  it  must  be  marked  invalid  {p  = 

invalid). 

In  general,  solving  conditional  disjunctive  constraints  is  NP-complete,  by  reduction  from  satisfiability  of 
boolean  formulae  in  3-conjunctive  normal  form.  However,  we  can  exploit  the  particular  structure  of  this 
inference  problem  to  find  a  solution  more  efficiently. 

Our  goal  is  to  minimize  the  number  of  global  pointers.  The  conditional  disjunctive  constraints  may 
leave  us  with  a  choice  between  having  a  global  valid  pointer  and  a  local  invalid  one.  If  either  would  be 
correct,  we  will  always  prefer  local  invalid.  Of  course,  if  that  pointer  is  required  to  be  valid  elsewhere, 
then  local  invalid  is  not  an  option  and  we  must  choose  global  valid  instead. 

The  constraints  have  two  important  properties.  First,  the  constraints  on  types  can  induce  constraints  on 
qualifiers,  but  constraints  on  qualifiers  do  not  introduce  constraints  on  types.  Thus,  we  can  resolve  the  type 
constraints  to  obtain  the  complete  set  of  qualifier  constraints.  Second,  the  conditional  qualifier  constraints 
mention  only  global/local  qualifiers  in  the  antecedents.  This  observation  suggests  the  following  procedure 
for  selecting  a  best  solution  of  the  constraints: 

1.  Assume  that  initially  we  have  an  unqualified  static  typing  for  the  program.  That  is,  we  know  what  is 
a  pointer,  pair,  or  integer,  but  we  do  not  know  which  pointers  are  local,  global,  valid,  or  invalid. 

2.  Using  the  equivalences  at  the  bottom  of  Figure  10,  expand  the  type  constraints  r  =  t'  and  t  <  t'  to 
obtain  the  complete  set  of  qualifier  constraints. 

3.  Solve  the  unconditional  equality  and  inclusion  constraints  on  p  variables.  Set  any  p  variable  not 
required  to  be  valid  to  invalid.  At  this  point  all  p  variables  are  resolved. 
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A  h  J  :  int 


A(x )  =  r 
A  h  x  :  t 


A(f)  =  t  — >  t'  A  h  e  :  r 

A  h  /  e  :  t' 

A  h  e  :  r 

A  h  |  e  :  boxed  local  valid  r 
A  h  e  :  boxed  w  valid  r  expand{u>,T,T') 

A  h  je  :  t' 


A  h  e  :  t  expand(global,  t,  t') 


A 

h 

transmit 

e  :  r‘ 

i 

A 

h 

e 

:  r 

A  1 

-  e'  : 

t' 

A 

h  e  ; 

e'  : 

:  t’ 

A 

h 

e 

:  boxed  valid  r 

A 

h 

e! 

:  r 

robust(u>, 

T) 

A 

h  e  :: 

-e! 

:  r 

A 

h 

ei 

:  n 

A 

1-  e2 

:  t2 

A 

h 

(ei,e2 

>  : 

(n,r2; 

) 

A 

h 

e  : 

:  boxed  u) 

p  (n, 

t2) 

Ah  @n  e  :  boxed  u ;  p  rn 


A  h  e  :  boxed  local  p  r 
A  h  e  :  boxed  global  p  r 

Figure  14:  Type  inference  rules.  Rules  above  the  dotted  line  correspond  directly  to  type  checking  rules  in 
Figure  12,  while  the  rule  below  the  line  is  new. 
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expand(u boxed  to  p  r,  boxed  a/  p' t')  =  {lu*  <  a/,  u>  <  to' ,  p  =  p' ,  r  =  t'} 

expand(uj*,  (ti,t2),  (t},t2))  =  pop(u*,  n,  r{)  U  pop(u*,  r2,  t2) 

expand(w*  ,  t,  t')  =  {r  =  r7}  otherwise 


pop(u>* ,  boxed  oj  p  r,  boxed  u/  p'  t/) 
pop(u*,  (ti,t2),  (t],^)) 
pop{uj*,T ,  t') 


=  {w*  =  global  =>  (w  =  global  \J  p'  =  invalid),  u;  =  a/,  r  =  t'} 

-  pop{uj* ,  n ,  )  U  pop(w* ,  r2 ,  rg) 

=  {r  =  r'}  otherwise 


robust(ui* ,  boxed  a >  p  t) 
robust{u> *,  (ti,t2)) 
robust(u>* ,  r) 


=  {w*  =  global  =>  (w  =  global  Vp  =  invalid)} 

=  robust(u)* ,  ri)  U  robust(u> *,  r2) 

=  0  otherwise 


Figure  15:  Constraint  generating  functions. 


4.  Remove  conditional  constraints  of  the  form 

w*  =  global  ==>  (w  =  global  V  invalid  =  invalid) 
These  are  always  satisfied. 

5.  Replace  conditional  constraints  of  the  form 

w*  =  global  =>  (w  =  global  V  valid  =  invalid) 


by  simply  oj*  <  uj. 

6.  Resolve  the  conditional  and  unconditional  constraints  on  a;  variables.  Set  any  w  variables  not  required 
to  be  global  to  local.  Note  that  the  conditional  constraints  no  longer  mention  p  variables,  so  this 
step  cannot  introduce  an  inconsistency.  It  is  easy  to  show  that  there  is  a  unique  solution  minimizing 
the  number  of  o>  variables  resolved  to  global.  This  devolves  to  graph  reachability,  computable  in  time 
linear  with  respect  to  the  number  of  global  qualifiers  in  the  solution  [15, 19]. 

7.  Complete  the  program  by  adding  a  minimal  set  of  explicit  widen  operators  wherever  the  new  local-to- 
global  coercion  rule  has  been  used.  This  is  similar  to  Henglein’s  ininimal  completions  [18],  but  with 
neither  induced  coercions  nor  projections,  and  requiring  only  a  linear-time  pass  across  the  derivation 
tree. 

We  note  that  setting  all  possible  variables  to  global  and  valid  will  always  produce  one  legitimate 
solution  to  the  constraints.  Thus,  languages  that  require  all  pointers  to  be  global  are  safe,  albeit  overly 
conservative. 


5  Experimental  Implementation 

5.1  A  Practical  Need  for  Sound  Inference 

Titanium  is  an  experimental  language  for  high-performance  parallel  computing.  Titanium  has  the  syntax 
and  semantics  of  Java,  although  it  compiles  to  native  machine  code  rather  than  virtual  machine  bytecodes. 
Titanium  extends  Java  with  a  global  address  space,  where  processes  can  address,  read,  and  write  each  other’s 
data  [20]. 

By  default,  all  references  in  a  Titanium  program  are  assumed  to  be  global.  This  makes  it  easy  to  build 
simple  programs  that  work.  It  is  also  a  suitable  choice  for  architectures  with  true  shared  memory  (SMP’s), 
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which  Titanium  also  supports.  However,  when  tuning  a  program  for  speed,  programmers  may  selectively 
declare  some  references  as  local  ( e.g .  within  inner  loops).  If  the  programmer  knows  that  a  large  array  is 
always  local,  a  local  declaration  causes  the  Titanium  compiler  to  produce  more  efficient  code  to  traverse 
the  local  array.  The  compiler  checks  explicit  local  qualifiers  statically,  using  rules  similar  to  those  presented 
here.  For  example,  if  a  method  expects  a  local  pointer  as  a  parameter,  passing  it  a  global  pointer  is  a  simple 
type  error  [30]. 

This  design  allows  programmer  to  ignore  locality  issues  until  the  code  is  running  correctly  and  then  add 
local  qualifiers  to  speed  things  up.  However,  Titanium  does  not  provide  qualifier  inference,  and  experience 
working  with  application  developers  has  shown  that  adding  local  qualifiers  by  hand  is  not  easy.  Arrays  of 
arrays  of  arrays  are  bewildering;  static  type  errors  are  often  reported  far  away  from  the  site  of  the  offending 
declaration;  and  the  more  aggressive  one  is  at  adding  local  qualifiers,  the  harder  it  is  to  maintain  a  valid 
program  in  the  long  run. 

Maintenance  issues  become  dominant  when  dealing  with  legacy  code.  Titanium  incorporates  a  large 
portion  of  the  standard  Java  class  library  into  its  own  runtime  environment.  The  complete  contents  of  the 
java.io,  java.lang,  and  java. util  packages  are  available  in  Titanium.  The  Titanium  compiler  produces 
native  code  directly  from  Sun’s  Java  source  code  for  these  packages.  Incorporating  the  standard  Java  libraries 
is  very  desirable:  the  libraries  represent  an  enormous  amount  of  work  that  does  not  need  to  be  repeated. 

However,  this  large  body  of  existing  code  was  written  for  Java,  not  Titanium.  The  three  packages 
comprise  sixteen  thousand  lines  of  source  code  without  local  qualifiers.  None  of  this  code  uses  Titanium’s 
cross-processor  communication;  but  in  the  absence  of  explicit  qualifiers,  every  variable,  field,  and  method 
parameter  defaults  to  a  global  reference.  Methods  are  assumed  to  return  global  references,  making  it  even 
more  difficult  for  programmers  to  use  local  references  in  their  own  code.  Manually  annotating  this  large  body 
of  legacy  Java  code  would  be  very  tedious  and  would  need  to  be  redone  with  each  new  release  from  Sun.  Yet 
without  reducing  these  global  references  to  local,  it  may  be  impossible  to  achieve  acceptable  performance. 

Practical  local  qualification  has  proven  unexpectedly  difficult  for  programmers.  Furthermore,  formally 
defining  how  local  qualification  may  be  used  in  a  sound  manner  has  been  an  ongoing  source  of  bugs  in  the 
Titanium  language  design.  For  these  reasons,  we  have  implemented  a  local  qualification  inference  engine, 
LQI,  and  made  it  available  as  an  optimization  within  the  Titanium  compiler. 

5.2  Accommodating  Titanium  Features 

Titanium  contains  many  features  not  present  in  the  languages  presented  earlier.  However,  these  may  all 
be  handled  without  difficulty;  the  core  issues  of  type  expansion  and  pointer  validity  can  be  extended  to 
accommodate  a  realistic  language.  We  briefly  describe  the  highlights. 

Titanium  is  object-oriented,  with  methods,  inheritance,  and  class-  and  interface-based  polymorphism. 
A  method’s  actual  arguments  must  match  its  formals;  thus,  if  a  method  is  observed  to  receive  a  global 
argument  in  any  context,  the  corresponding  formal  parameter  is  constrained  to  be  global  within  the  method 
body.  Titanium  permits  implicit  coercion  from  local  to  global,  so  a  method  can  receive  a  local  argument  in 
one  context  and  a  global  elsewhere.  The  local  argument  is  widened  at  the  point  of  the  call. 

Native  methods,  which  are  implemented  by  external  C  code,  are  treated  conservatively.  Because  the 
compiler  has  no  access  to  the  implementation,  it  is  never  safe  to  change  either  the  formal  parameter  types 
or  the  return  type  of  a  native  method.  This  conservative  approach  can  be  taken  in  any  situation  where 
only  partial  information  is  available.  For  example,  while  the  analysis  is  currently  whole-program,  it  could 
be  made  to  accommodate  separate  compilation  by  forcing  conservative  analysis  at  module  boundaries. 

Inheritance  simply  induces  additional  constraints  between  parent  and  child  classes.  A  subclass  is  con¬ 
strained  to  use  identical  types  for  any  fields  inherited  from  its  parent.  Interfaces  and  overridden  methods 
are  handled  in  the  same  manner. 

Arrays  are  treated  similarly  to  references.  An  array  of  references  is  akin  to  a  pointer  to  an  n-tuple  of 
homogeneously-typed  pointers.  A  particularly  tricky  issue  is  handling  type  casts  involving  arrays.  When 
an  array  is  implicitly  cast  to  Object,  we  forbid  changes  to  any  “forgotten”  qualifiers  below  the  topmost 
level  of  the  array  type.  When  an  Object  is  dynamically  cast  back  to  an  array  type,  we  also  forbid  changes 
to  any  “remembered”  qualifiers  below  the  topmost  level.  By  holding  the  qualifiers  fixed  in  both  cases,  we 
ensure  that  any  dynamic  casts  will  behave  identically  in  the  original  and  optimized  programs.  Otherwise,  if 
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Benchmark 

Naive 

Effect  on 

LQI 

Speed 

Improvement 

Effect 

Naive 

on  Code  Size 

LQI  Improvement 

cannon  manual 

53.4  sec 

50.3  sec  5.7% 

43.5  MB 

23.4  MB 

46.2% 

cannon  auto 

58.1 

51.3 

13.2% 

43.0 

23.6 

45.2% 

lu-fact  manual 

131.4 

130.1 

<  1.0% 

78.1 

44.6 

42.9% 

lu-fact  auto 

227.1 

131.3 

42.2% 

87.4 

44.9 

48.7% 

sample 

29.2 

21.4 

26.6% 

40.5 

20.3 

49.8% 

gsrb 

16.0 

15.7 

1.9% 

99.1 

64.4 

35.0% 

pps 

92.2 

40.3 

56.3% 

545.0 

309.8 

43.2% 

Table  2:  Titanium  benchmark  performance. 


qualifiers  were  changed  in  the  array  declaration  but  not  the  explicit  cast,  or  vice  versa,  dynamic  cast  failures 
would  occur  where  none  existed  in  the  original  program. 

5.3  Local  Qualification  Inference  for  Titanium 

As  implemented  in  the  Titanium  compiler,  the  LQI  optimization  is  slightly  less  powerful  than  the  inference 
system  presented  in  Section  4.  The  initial  pass,  which  identifies  references  that  must  remain  valid,  is  omitted. 
Instead,  it  is  assumed  that  all  references  must  be  valid  at  all  times.  This  is  safe,  if  overly  conservative.  In 
some  cases,  when  data  is  copied  across  processors  but  never  subsequently  used,  the  validity  assumption  may 
force  references  to  be  global  when  they  could  have  been  local  invalid. 

We  have  measured  the  effectiveness  of  LQI  optimization  on  several  numerical  kernels  and  applications. 
These  include: 

cannon  Cannon’s  algorithm  for  dense  matrix  multiplication.  We  multiply  a  pair  of  random  256  x  256 
matrixes. 

lu-fact  LU  factorization  for  dense  matrixes.  We  factor  a  1024  x  1024  element  random  matrix,  partitioned 
into  sixty  four  128  x  128  element  blocks. 

sample  Sample  sort,  a  distributed  sorting  algorithm.  We  sort  220  thirty  two  bit  integer  keys,  with  64  keys 
per  sample. 

gsrb  The  Gauss-Seidel  Red  Black  algorithm  for  solving  elliptic  partial  differential  equations.  We  solve  a 
2048  x  128  element  problem,  partitioned  into  four  512  x  128  element  patches  across  100  full  iterations. 

pps  A  parallel  solver  for  the  Poisson  equation  with  infinite  domain  boundary  conditions.  We  solve  a  512  x  512 
element  problem  partitioned  into  four  128  x  128  element  patches,  with  a  refinement  ratio  of  16  between 
coarse  and  fine  grids. 

In  all  cases,  the  programs  were  run  in  parallel  on  four  nodes  of  the  Berkeley  Network  of  Workstations 
(NOW)  [1,12].  Cross-processor  reads  and  writes  are  implemented  by  sending  messages  from  node  to  node, 
with  Active  Messages  II  providing  the  lightweight  fast  messaging  substrate  [23]. 

Table  2  shows  our  experimental  results.  Note  that  for  cannon  and  lu-fact,  two  sets  of  measurements 
were  taken.  The  “manual”  measurements  reflect  the  code  as  originally  produced  by  the  programmer.  In 
both  cannon  and  lu-fact,  the  programmer  had  already  deployed  numerous  explicit  local  qualifiers  in  an 
effort  to  speed  up  the  code.  Thus,  the  “manual”  measurements  reflect  the  additional  speedup  available 
from  local  qualification  opportunities  that  the  programmer  missed,  even  in  these  relatively  small  kernels. 
The  “auto”  variants  use  the  same  code  but  with  all  explicit  local  qualifications  removed.  These  reflect  the 
opposite  extreme,  where  a  programmer  has  relied  completely  upon  LQI. 

As  one  would  expect,  the  manual  variants  show  less  relative  benefit  than  their  auto  counterparts.  For 
lu-fact,  the  programmer  has  already  added  so  many  explicit  qualifications  as  to  leave  little  room  for  further 
improvement.  However,  the  same  programmer  missed  a  few  important  spots  in  cannon,  even  though  the 
entire  program  is  only  180  lines  long.  LQI  was  able  to  discover  and  optimize  these  for  a  5.7%  net  speedup. 
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For  both  cannon  and  lu-fact,  manual  annotation  plus  LQI  is  just  slightly  faster  than  LQI  alone.  Human 
programmers  can  add  explicit  casts  that  recover  local  qualifiers,  but  which  are  only  correct  due  to  deep 
properties  of  the  program  that  static  analysis  cannot  reveal.  This  affirms  our  hypothesis  that  the  best  design 
combines  selective  manual  annotation  with  aggressive,  sound  inference. 

The  measurements  as  a  whole  show  that  improvement  varies  widely  from  program  to  program.  In  a 
sense,  LQI  identifies  the  portion  of  a  calculation  that  takes  place  locally,  and  optimizes  that  to  run  using 
fast  local  pointers.  Thus,  the  benefit  to  be  gained  is  directly  dependent  upon  the  locality  of  the  underlying 
algorithms.  A  program  that  genuinely  uses  lots  of  cross-processor  data  will  harbor  few  opportunities  for 
local  qualification.  Conversely,  an  algorithm  that  has  been  specifically  designed  for  scalable  distributed 
operation  will  perform  most  work  locally,  and  only  communicate  very  rarely.  Such  algorithms  will  show 
larger  speedups  from  LQI,  and  the  relative  speedup  will  become  greater  when  working  on  increasingly  large 
problems.  This  is  particularly  evident  in  pps,  a  fairly  new  algorithm  that  is  specifically  designed  for  scalable 
distributed  operation.  It  performs  relatively  more  local  calculations  than  gsrb,  but  is  thereby  able  to 
greatly  reduce  the  amount  of  cross-processor  communication  [3].  Because  communication  is  so  costly,  this 
gives  much  better  performance  in  general,  and  meshes  particularly  well  with  LQI,  for  an  impressive  speedup. 
The  anecdotal  experience  of  the  programmer  who  wrote  pps  is  illuminating.  When  asked  if  he  had  previously 
put  in  many  explicit  local  qualifiers,  he  replied  “Yes,  but  apparently  not  anywhere  that  it  mattered.”  LQI’s 
analysis  is  more  thorough  and  56.3%  more  effective. 

The  primary  concern  of  most  Titanium  programmers  is  execution  speed.  However,  LQI  also  makes  code 
smaller.  As  Titanium  is  implemented  on  the  NOW,  local  pointers  require  many  fewer  instructions  to  use. 
Table  2  shows  that  LQI  makes  the  benchmarks’  code  segments  35%  to  50%  smaller.  These  sizes  exclude 
code  for  the  standard  Java  classes,  like  String  or  Math.  If  the  standard  classes  are  included  as  well,  the 
overall  reduction  is  smaller,  from  13%  to  18%  for  a  complete  executable. 

6  Related  Work 

Nearly  one  hundred  distributed  programming  languages  were  identified  ten  years  ago  [2],  and  many  more 
have  appeared  since.  We  highlight  some  representative  examples  of  approaches  previously  taken  to  the 
local/global  pointer  problem. 

Olden  adds  parallelism  to  C,  focusing  on  dynamic  structures  augmented  with  compiler-directed  software 
caching  and  migration  [9, 10,27].  All  Olden  pointers  are  global,  so  it  is  never  possible  to  see  an  invalid  local 
pointer  from  another  processor’s  address  space.  However,  pointer  operations  require  four  extra  instructions 
to  test  the  processor  ID  and  decode  the  machine  address.  Data  flow  analyses  can  eliminate  some  redundant 
checks,  but  address  decoding  always  adds  one  instruction  of  overhead.  The  inference  described  in  this 
paper  could  complement  these  analyses,  using  a  faster  (unencoded)  representation  for  those  pointers  that 
are  statically  guaranteed  to  be  local. 

Emerald  also  focuses  on  fine-grained  object  mobility  [21].  While  local  and  global  are  not  distinguished 
at  the  source  level,  selected  object  fields  may  be  declared  as  attached.  Because  an  object  and  its  transitively 
attached  fields  always  live  in  the  same  address  space,  the  compiler  can  use  fast  local  addresses  to  implement 
attached  fields.  This  is  a  safe  alternative  to  the  techniques  presented  here,  but  may  require  more  data  motion 
to  keep  attached  fields  colocated  as  objects  migrate. 

Cid  [25],  Split-C,  and  Titanium  explicitly  distinguish  local  and  global  in  the  source  language.  Cid  uses 
a  single  type  for  all  global  pointers,  the  distributed  equivalent  of  void  *.  Split-C  assumes  all  pointers  local 
unless  declared  otherwise,  while  Titanium  references  default  to  global.  Cid  and  Split-C  make  little  effort  to 
enforce  soundness;  while  this  is  consistent  with  C’s  low-level  approach,  the  difficulty  of  distributed  debugging 
compounds  the  standard  issue  of  wild  pointers.  Titanium  attempts  to  be  as  safe  Java,  and  does  address 
some  of  the  issues  highlighted  in  Section  3.  However,  it  does  not  do  so  consistently  or  completely,  and  one 
can  easily  craft  unsound  expressions.  Those  remaining  holes  can  now  be  closed  in  light  of  this  research. 

Certain  aspects  of  our  approach  may  be  applicable  to  other  models  of  distributed  computing,  such  as 
those  based  on  remote  procedure  calls  [6] .  Inferred  type  qualifications  might  allow  specialized  marshaling  for 
particular  recipients.  For  example,  Java  has  no  global  pointers,  so  when  an  object  is  marshaled  using  Java 
remote  method  invocation,  all  other  objects  transitively  reachable  from  it  must  be  marshaled  as  well  [28]. 
Inference  of  invalid  qualifiers  would  let  the  sender  prune  this  reachability  graph  if  the  recipient  were  known 
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to  never  traverse  certain  pointers.  Conversely,  CORBA  objects  always  reference  each  other  with  network- 
aware  handles  [26].  Inference  of  local  qualifiers  could  replace  some  handles  with  simple  local  pointers, 
thereby  reducing  overhead.  In  general,  any  system  based  on  distributed  objects  may  be  able  to  leverage 
qualification  inference  to  simplify  representations  of  data  that  never  actually  span  the  network. 


7  Conclusions  and  Future  Work 

Distributed  computing  environments  have  distinct  notions  of  local  and  remote  memory.  However,  explicitly 
distinguishing  between  pointer  types  creates  several  opportunities  for  unsoundness.  We  have  described  a 
suite  of  type  systems  that  clarify  these  problems  and  demonstrate  how  they  can  be  avoided.  A  simple, 
asymptotically  efficient  type  inference  system  can  automatically  insert  an  optimal  set  of  qualifiers,  reducing 
the  burden  on  the  programmer.  Experiments  with  the  Titanium  language  show  that  inference  can  greatly 
improve  performance,  particularly  for  codes  specifically  designed  for  scalable  distributed  execution. 

The  systems  presented  here  could  be  enhanced  in  three  important  ways.  First,  the  assumption  of  a  two- 
level  memory  could  be  generalized  to  n  levels  of  partitioned  address  spaces.  This  may  become  important  as 
simple  distributed  uniprocessors  give  way  to  clusters  of  SMP’s,  clusters  of  clusters,  and  other  deep  parallel 
hierarchies.  Second,  the  model  should  be  extended  to  include  mobile  code,  an  area  of  growing  interest.  A 
simple  approach  may  be  to  require  that  only  robust  free  variables  appear  in  any  mobile  closure,  but  more 
study  is  needed.  Finally,  polymorphic  analysis  of  functions  could  be  beneficial.  For  example,  this  would  let 
Titanium’s  LQI  automatically  produce  both  local  and  global  variants  of  standard  container  classes  like 
Vector  or  Hashtable,  for  potentially  larger  improvements  to  performance. 
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A  Operational  Semantics  and  Soundness 

In  this  appendix  we  prove  that  the  type  checking  system  presented  in  Section  3.3  is  sound  with  respect  to  an 
operational  semantics.  We  focus  on  the  sequential  subset  of  the  language,  which  includes  everything  except 
transmit  expressions.  Because  the  semantic  problems  with  local  and  global  pointers  are  the  representation 
and  movement  of  pointers  between  address  spaces,  dealing  with  concurrency  complicates  the  semantics  while 
also  obscuring  the  core  issues.  The  language  subset  we  work  with  is: 

e  ::=  J|a;|/e|fe|J,e|  widen  e  | 

ei  ;  e2  |  e\  :  =  e2  |  (ei,e2)  |  @1  e  |  @2  e 

Furthermore,  we  restrict  primitive  functions  to  be  mappings  from  integers  to  integers.  This  simplifies  the 
proof  without  hiding  any  core  issues. 

A.l  Semantic  Domains 

We  use  the  following  semantic  domains.  The  treatment  of  stored  pairs  is  unusual  and  is  explained  below. 


M 

the  set  of  machines 

A 

the  set  of  local  addresses 

Id 

the  set  of  identifiers 

T 

the  set  of  all  types 

G  = 

M  x  A 

global  addresses 

V  = 

J+A+G+ V x V 

values 

SV  = 

J  +  A  +  G  +  Ax  A 

values  that  can  be  stored 

We  use  the  following  conventions  for  naming  elements  of  the  semantic  domains. 


m,  mo,  m! , . . .  £  M 
v,v0,v', . . .  £  V 
sv,  sv o,  sv', . . .  £  SV 
S,S0,S',...£  Store 
E  £  Env 
e,  e0,  e', . . . 
it  fo,  i  t  •  •  •  £  ^ 
9:90td\  ■  ■■  £  G 
a,  a0,  a',. . .  £  A 


a  machine 
a  value 

a  storable  value 
a  store 

the  environment 
a  source  expression 
an  integer 
a  global  pointer 
a  local  pointer 


In  the  operational  semantics,  the  use  of  i,  a,  or  g  in  a  hypothesis  should  be  read  as  a  constraint,  not  a 
comment.  That  is,  a  hypothesis  e  — >  *  means  that  e  must  evaluate  to  an  integer  for  the  rule  to  be  applicable. 

We  write  global  addresses  as  a  pair  (m,  a)  of  machine  and  local  address.  Global  addresses  can  be 
distinguished  from  pair  values  {v\,v2)  by  context,  as  machines  cannot  be  a  component  of  pairs. 

A  store  is  a  finite  function  from  global  addresses  to  values.  When  a  value  is  created  a  new  location  in 
the  store  must  be  allocated.  The  function 


new  :  Store  x  M  — >  A 


takes  a  store  and  a  machine  m  and  returns  a  fresh  local  address.  We  also  use  a  shorthand 


newn(m,  S)  =  (ai,...,a„) 

to  simultaneously  obtain  n  distinct  fresh  addresses  in  a  local  memory.  By  “fresh”  we  mean  that  new  satisfies: 

new(m,  S)  =  a  =>  a  ^  dom(Xao.S((m,ao))) 

In  other  words,  the  new  address  is  not  already  in  use  on  machine  m. 

Our  treatment  of  pairs  is  unusual.  Unboxed  pairs  are  treated  as  values,  but  only  pairs  of  addresses  are 
placed  in  the  store.  Because  the  operations  @1  and  @2  take  the  addresses  of  pair  components,  and  because 
these  addresses  are  then  first-class  values,  we  must  model  the  location  in  the  store  of  the  components  of  the 
pair  as  well  as  the  pair  itself.  This  is  done  most  directly  by  simply  storing  the  two  components  of  the  pair  at 
different  addresses,  rather  than  more  usual  solution  of  representing  the  entire  pair  value  with  a  single  address. 
To  maintain  the  knowledge  that  these  two  components  represent  a  pair  we  store  the  pair  of  addresses  at  the 
address  of  the  pair  itself. 

For  example,  consider  an  unboxed  pair  consisting  of  two  integers  (5,  6).  Taking  the  address  j(5,  6)  forces 
the  pair  to  be  placed  in  the  store  S.  Three  new  locations  on  the  local  machine  rn  are  allocated  to  store  the 
pair: 


S((m,  ai))  =  (a2,a3) 

S((m,a2 ))  =  5 
S((m,  a3))  =  6 

The  value  of  |(5,6)  is  the  pair  address  a±.  Selecting  the  address  of  the  first  field  @1  f(5,6)  yields  the  value 
a2. 

Nested  pair  values  are  stored  recursively  when  boxed.  Thus  the  expression  "f((5,6),7)  allocates  five  new 
locations  in  the  local  store  for  the  three  integers  and  two  pairs: 


S{(m,a0)) 
S((m,a  i)) 
S((m,  a2)) 
S{(m,a3 )) 
S((m,  a4)) 


(ai,a4) 

(02,03) 


5 

6 
7 
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In  practical  language  implementations  only  the  “leaf”  values  5,  6,  and  7  are  stored  and  the  knowledge  of  the 
grouping  of  the  addresses  into  pairs  is  maintained  implicitly  inside  the  compiler.  The  stored  pair  values  are 
the  semantic  representation  of  this  compiler  knowledge. 

Unboxing  a  nested  pair  is  the  inverse  of  boxing  a  pair:  any  stored  address  pairs  are  traversed  recursively 
to  recreate  the  unboxed  value.  In  the  example  just  given  [  f  ((5,  6),  7)  is  the  value  ((5,  6),  7). 

A. 2  Operational  Semantics 

Operational  rules  have  the  form: 


to,  Sq,  E  b  e  — >  v,  Si 

which  should  be  read  “on  a  given  machine  to  in  store  So  and  environment  E,  the  expression  e  evaluates  to 
the  value  v  and  produces  a  new  store  Si .” 

The  rules  for  integer,  variable,  and  function  application  expressions  are  simple. 


E(x)  =  v  G  V 

m,S,E  b  i  — >  i,  S  to,  S,  E  b  x  — >  v,  S 


m,So,E  b  e  — >  i,  S i 
E(f)  =  <j>  £  Fun  <j>{i)  =  i! 
to,  So,  E  b  /e->  i',S\ 

The  rules  for  referencing  and  dereferencing  values  are  more  elaborate.  We  need  a  number  of  auxiliary 
functions.  Let  a  ■  ( b,c )  =  ( a,b,c )  be  a  tuple  append  operator.  Append  may  also  be  applied  on  the  right 
(b,  c)  ■  a  =  ( b ,  c,  a)  and  to  sets  of  tuples: 

a  ■  B  =  {a  ■  b  \  b  £  B} 

A  path  is  a  tuple  with  elements  appearing  in  an  order  described  by  the  regular  expression  (J  \  \)*sv.  That 
is,  a  path  consists  of  a  sequence  of  J  and  \,  except  for  the  last  element  which  is  a  storable  value.  A  path 
describes  a  sequence  of  selections  within  nested  pairs  (taking  either  the  left  or  right  component)  to  reach  a 
storable  value.  We  write  t,  to,t' , . . .  to  denote  paths. 

A  pure  path  is  a  tuple  with  elements  appearing  in  an  order  described  by  the  regular  expression  (/  |  \)*. 
We  write  p,Po,p' ,  ■  ■  ■  to  denote  pure  paths.  Figure  16  defines  a  number  of  functions  on  paths  and  values. 

Taking  the  address  of  any  value  but  a  pair  simply  boxes  the  value  by  allocating  a  local  address  on  the 
current  processor  and  storing  the  value  at  that  address.  As  described  above,  the  components  of  pairs  are 
recursively  boxed. 


to,  Sq,  E  b  e  — >  v,  Si 

Paths(v )  =  {pi, . . .  ,pi,pi+ 1  •  svi+i, ... ,pn ■  sun}  where  pi  =  () 
newn(m,  Si)  =  {ai, . . . ,  an} 

svi  =  ( aj,ak )  where  pv  J=  pj  and  pi-  \=  pk,  for  1  <  i  <  l 
_ S2  =  Si[(m,a  i)  *-  svi,...,  ( m,an )  <—  sura] _ 

m,So,E  b  te— >ai,S,2 

For  dereferences  there  are  two  cases.  For  a  dereference  of  a  local  pointer,  we  use  the  auxiliary  function 
Value  defined  in  Figure  16  to  unbox  the  value.  For  a  dereference  of  a  global  pointer  we  use  auxiliary  function 
WideValue,  which  widens  any  local  pointer  appearing  at  the  top  level  but  is  otherwise  identical  to  Value. 

m,So,E  b  e  — >  a,  S\ 
to,  So,  E  b  J,  e  — >  Value(S i,  (m,  a)),  Si 
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Paths(v) 
LeafPaths{v ) 

LeafAddresses(S,  (to,  a)) 


Valuers ,  (to,  a)) 


Wide  Valuers,  (to,  a)) 


I  {()}  u  U  -Paths(v i))  U  (\  • Paths(v2 ))  if  v  =  (vi,v2) 
]{(t;)}  otherwise 

{x  |  x  £  Paths(v)  A  x  =  p  ■  si;} 

!(/  -LeafAddresses(S,  (m,a  1)))  if  S((m,a ))  =  (<21,02) 

U  (\  -LeafAddresses(S,  (171,02))) 

{ (  (to  ,  a) ) }  otherwise 

!( Value(S ,  (to,  S((m,  ai)))),  if  S((m,  a})  =  (01, 02) 

Value(S ,  (to,  S((m,  a2))))) 

S((m,  a))  otherwise 

f  (to,  a')  if  S((m,  a))  =  a' 

[  Value(S,  (to,  a))  otherwise 


Figure  16:  Auxiliary  functions  for  boxing,  unboxing,  and  assignment. 


_ to,  Sp,  E  h  e  — >  g,Si _ 

m,So,E  h  |e— >  FfrideVaZMe(S'i,5),  S1! 

The  rules  for  widening,  sequencing,  and  pairing  are  straightforward. 

to,  Sq,  E  b  e  —>  a,  S\ 
to,  Sq,  E  b  widen  e  — >  (to,  a),  5i 

m,So,E  b  ei—>Vi,Si 
m,S\,E  b  e2  — >  v2,  S2 
m,  Sq,  E  b  ei  ;  e2  — >•  v2,S2 


to,  Sq,  E  b  ei  — >v\,Si 
m,Si,E  b  e2  — >  v2,S2 
m,S0,E  b  (ei, e2)  — >  (v\,v2),S2 

The  rule  for  assignment  is  complicated  by  the  semantics  of  assigning  into  pairs.  Assume  a  is  a  boxed  local 
pointer  to  a  pair  of  integers.  Then  the  assignment  a  :=(1,2)  overwrites  the  two  integers  of  the  pair  in  the 
store  with  the  integers  1  and  2.  This  semantics  corresponds  directly  to  the  structure  assignment  primitive  in 
the  C  programming  language.  The  auxiliary  functions  Leaf  Addresses  and  LeafPaths  in  Figure  16  provide  the 
mechanism  for  matching  addresses  with  the  values  to  be  assigned.  Note  that  in  the  case  where  S((m,  a})  and 
v  are  not  pairs,  the  sets  of  leaf  addresses  and  leaf  values  are  just  {((to,  a))}  and  {(u)}  respectively.  There 
are  two  cases  of  assignment:  one  for  assigning  across  a  local  pointer  and  one  for  assigning  across  a  global 
pointer. 


m,So,E  b  ei  — >  a,  Si 
to,  Si,E  b  e2  — >  v,  S2 

LeafAddresses(S2,  (to,  a))  =  {pi  ■  gx, . . .  ,pn  ■  gn} 
LeafPaths{v)  =  {pi  ■  svi, . . .  ,pn  ■  si>„} 
_ S3  =  S2[g 1  <-  sir,  •  •  •  ,gn  svn] _ 

to,  So,  E  b  ei  :  =  e2  — >  v,  S3 
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to,  So,  E  b  ei  ->  g,Si 
m,Si,E  h  e2  — >  u,  S2 
LeafAddresses(S2 ,  ff)  =  {pi  ■  ffi,  ■  •  •  •  gn} 

LeafPaths[v)  =  {p±  ■  sv i, . . .  ,pn  ■  swn} 

_ S3  =  S2[gi  <-  sv  1, .  • .  ,gn  <—  si>ra] _ 

m,S0,E  b  ei:  =  e2—>v,S3 

The  final  four  rules  implement  the  @n  operators,  which  return  the  addresses  of  pair  components. 

m,So,E  b  e  — >  a,  S\  Si((m,a))  =  (ai,a2) 

m,So,E  b  @1  e  — >ai,5i 

m,So,E  b  e  — >  a,  Si  Si((to,  a))  =  (ai,  02) 

m,So,E  b  @2e— »a2,5'i 

m,So,E  b  e—*(m',a),Si  Si({m' ,a})  =  (ai,a2) 

m,So,E  b  @1  e  — >  (to',  ai),  Si 

m,So,E  b  e—>{m',a),Si  Si((m',a))  =  (ai,a2) 

m,So,E  b  @2  e  — ►  (to',  02),  Si 


A. 3  Soundness 

Before  we  can  prove  type  soundness  we  need  to  state  what  representation  we  expect  the  values  of  types  to 
have.  Figure  17  defines  a  predicate  Consistent  that  recursively  compares  a  type  with  a  value  and  a  store  to 
check  that  the  value  matches  requirements  of  the  type.  We  say  that  a  store  S  on  machine  m  is  consistent 
with  value  v  and  type  r  if  Consistent{m,  S,  {v,t))  is  true.  We  extend  consistency  to  apply  to  sets  of  values 
and  types  as  well.  If  U  is  a  set  of  value/type  pairs,  then  Consistent(m ,  S,  U)  if  and  only  if  Consistent{m ,  S,  u ) 
for  all  u  £  U. 

To  prove  soundness,  there  is  another  issue  we  must  address.  Our  language  allows  pointer  aliasing,  and 
the  language  will  be  unsound  if  stored  pointer  values  can  be  given  different  types  by  different  aliases.  In 
particular, 


if  x  :  boxed  local  valid  boxed  local  invalid  r 

and  y  :  boxed  local  valid  boxed  local  valid  r 

and  x  and  y  happen  to  refer  to  the  same  pointer,  then  the  type  system  might  permit  an  assignment  of  an 
invalid  pointer  into  x,  thereby  giving  y  a  value  that  disagrees  with  its  type.  The  Consistent  predicate  cannot 
detect  this  situation;  to  check  this  it  is  necessary  to  compare  all  the  different  typings  of  each  memory  address 
through  all  of  its  aliases  to  ensure  they  agree. 

The  function  StoreType  in  Figure  18  captures  the  needed  property.  A  StoreType  maps  mutable  locations 
to  types,  JL,  or  T.  The  ordering  of  elements  is  _L<  r  <  T,  with  all  types  r  being  incomparable.  The  least 
upper  bound  of  two  elements  is  the  smallest  element  that  is  >  to  both.  The  least  upper  bound  of  two 
functions  is  defined  point- wise: 


(/  LI  f')(x)  =  f(x)  U  f\x) 

If  a  store  typing  st  has  the  property  that  st(g)  =  T,  then  the  location  g  is  typed  differently  by  two  or 
more  aliases  of  the  location;  in  this  case  we  say  the  store  typing  st  is  not  uniform.  If  there  is  no  g  such  that 
st(g)  =  T  then  all  of  the  aliases  of  all  mutable  locations  agree  on  the  types  of  those  locations:  the  store 
typing  is  uniform.  Predicate  Uniform  in  Figure  18  formalizes  this  notion. 
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U  =  V  x  T 
U  €  2U 

u,  Mo,  u  .  £  U 


Consistent 


M  x  Store  x  U  — >  boolean 


Consistent(m ,  S',  (i,  int)) 
Consistent(m,  S,  (a,  boxed  local  invalid  r)) 
Consistent(m,  S,  (g,  boxed  global  invalid  r}) 


frwe 

tr-ue 

fr-ue 


Consistent(m,  S,  ({vi,V2),  (71,72))) 


Consistent(m,  S,  (vi,ti)) 
Consistent(m,  S,  {02,  T2}) 


Consistent(m,  S,  (a,  boxed  local  valid  r)) 


==>  S((m,a))  is  defined 

A  Consistent(m,S,(S((m,a)),T)) 
where  r  ^  (n,  T2) 


Consistent(m,  S,  (a,  boxed  local  valid  (ti,T2))) 


A 

A 


S{(m,  a})  =  (ai,  a2) 

Consistent(m,  S,  (01,  boxed  local  valid  ri)) 
Consistent(m,  S,  (02,  boxed  local  valid  T-2» 


Consistent(m,  S,  ({m1 ,  a) ,  boxed  global  valid  r)) 


=>■  S((m',a))  is  defined 

A  Consistent(m' ,  S,  (S((m  ,  a)),  r } ) 
where  r  ^  (n,  T2} 


Consistent(m,  S,  ({m',a),  boxed  global  valid  (n,T2))) 


A 

A 


S{(m,  a))  =  (01, 02) 

Consistent(m,  S,  ({m1 ,  ai),  boxed  global  valid  n)) 
Consistent(m,  S,  ({rn  , 02),  boxed  global  valid  T2}) 


Consistent{m,  S,  U) 


Consistent(m,  S,  u ) 

ueu 


Figure  17:  Consistent  stores. 
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ST 

Store  Type 

StoreType{m,  S,  ( i ,  int)) 
StoreType(m,  S,  (a,  boxed  local  invalid  r}) 
StoreType(m,  S,  ({m' ,  a),  boxed  global  invalid  r}) 

StoreType(m,  S,  ((xi,x2),  (ri,r2))) 

StoreType(m,  S,  (a,  boxed  local  valid  r)) 

StoreType(m,  S,  (a,  boxed  local  valid  (n,T2))) 

StoreType(m,  S,  ({m1 ,  a),  boxed  global  valid  r}) 

StoreType(m,  S,  ((m ,  a),  boxed  global  valid  (n,  r2)}) 

StoreType(m ,  S',  [/) 

Uniform 

Uniform(st) 


G  — >  (r+  -L  +T) 

:  M  x  Store  xlA  — >  ST 

=  A*.  X 

=  Ax.  X 

=  A*.  X 

=  StoreType(m,  S,  (vi,  n}) 

U  StoreType(m,  S,  (v2,  r2}) 

=  Aa;.  _L  [(m,  a)  <—  r] 

U  StoreType(m.,S,{S((m,a)),T)) 

where  r  ^  (n,  r2) 

=  Aa;.  _L  [(m,a)  <—  (ri,r2)] 

U  StoreType(m,  S,  (ai,  boxed  local  valid  n)) 

U  StoreType{m,  S,  (a2, boxed  local  valid  r2}) 

where  S((m,a))  =  (ai,a2) 

=  Ax.  X  [(ra^a)  <—  r] 

U  StoreType(m  ,  S,  (S((m  ,a)),r)) 

where  r  (n,  r2) 

=  Ax.  X  [(m',a)  <—  (ti,t2)] 

U  StoreType(m,  S,  ({m' ,  ai),  boxed  global  valid  n}) 

U  StoreType(m,  S,  ((m' ,  a2), boxed  global  valid  r2}) 

where  S((m,a))  =  (ai,a2) 

=  | |  StoreType(m,  S,u) 

u£U 

:  ST  — ►  boolean 

=>■  $g.st(g)  =  T 


Figure  18:  Uniform  store  typings. 
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Data  that  is  immutable  need  not  have  the  same  typing  for  every  alias.  StoreType  does  not  require  the 
top-level  pointer  encountered  in  its  traversal  of  a  value  to  have  a  uniform  view  everywhere.  This  pointer  is 
not  itself  mutable,  only  the  data  it  points  to  is  mutable. 

Finally,  the  full  notion  of  soundness  we  need  simultaneously  confirms  that  the  execution  and  type  envi¬ 
ronments  also  agree.  For  this  purpose  it  is  useful  to  combine  the  two  environments  pairwise,  matching  each 
variable’s  value  with  its  corresponding  type: 

E  N  A  =  {(E(x) ,  A(x))  €  U  |  x  €  dom(E)  n  dom(A)} 

For  the  soundness  proof  we  require  that  the  execution  and  type  environments  agree  from  the  outset;  that  is, 
dom(E)  =  dom(A). 

Because  we  do  not  have  any  iteration  constructs  in  our  small  language,  all  computations  are  terminating. 
We  can  use  this  fact  to  sidestep  the  usual  issues  with  showing  type  soundness  even  for  infinite  computations. 
We  simply  show  that  if  an  expression  has  any  type  then  computation  never  goes  wrong,  provided  the 
computation  is  performed  in  an  environment  consistent  with  the  typing  assumptions. 

A. 3.1  Lemmas  Relating  to  Store  Typing  Functions 

Lemma  1.  A  store  typing  function  is  not  changed  by  inclusion  or  exclusion  of  integers.  That  is,  for  any 
integer  i 


StoreType(m,  S,  U)  =  StoreType(m,  S,  U  U  {(*,  int)}) 
provided  that  the  first  store  typing  function  is  defined. 

Proof.  From  the  definition  of  StoreType ,  we  know  that  StoreType(m,  S,  ( i ,  int))  =  Ax.  _L  and  so 

StoreType{m,  S,  U) 

=  StoreType(m,  S,U)  U  Ax.  _L 
=  StoreType(m,  S,U)  U  StoreType(m,  S,  (i,  int)) 

=  StoreType(m,  S,  U  U  { (i,  int)}) 


□ 

Lemma  2.  A  global  pointer  induces  the  same  store  typing  function  as  an  equivalent  local  pointer  on  the 
remote  machine.  That  is, 

StoreType(mo,  S,  ((m,  a)  .boxed  global  p  r))  =  StoreType(m,  S,  (a,  boxed  local  p  r)) 

provided  that  the  first  store  typing  function  is  defined. 

Proof.  The  proof  is  by  induction  on  the  structure  of  r. 

Base  Case:  Invalid  Pointers  If  p  is  invalid,  then  both  store  typing  functions  are  Ax.  J_  and  therefore 
equivalent. 

Base  Case:  Valid  Pointers  to  Non-Pairs  Suppose  that  p  is  valid,  and  that  r  is  not  a  pair  type.  Then 

StoreType(mo ,  S,  ((m,  a),  boxed  global  valid  r)) 

=  Ax.  J_  [( m,a )  <—  r]  U  StoreType(m,  S,  (5((m,  a)),  r))  definition  of  StoreType 

=  StoreType(m ,  S,  ((m,  a),  boxed  local  valid  r))  definition  of  StoreType 
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Inductive  Case:  Valid  Pointers  to  Non- Pairs  Suppose  that  p  is  valid,  and  that  r  is  (ti,T2)  for 
some  T\  and  iq.  Since  we  require  that  the  first  store  typing  function  be  defined,  it  must  be  the  case  that 
S((m.,a))  =  (01,02)  for  some  01  and  02-  Then 


Store Type(mo,  S,  ((to,  a),  boxed  global  valid  (71,12))) 
=  Ax.  _L  [(to,  a)  <—  r] 

U  StoreType(m.o,  S,  ((to,  01) ,  boxed  global  valid  iq)) 
U  StoreType(mo,  S,  ((to,  02),  boxed  global  valid  72)) 
where  S((m,a))  =  (01,02) 

=  Ax.  _L  [(to,  o)  <—  r] 

U  StoreType(m,  S,  (ai,  boxed  local  valid  n)) 

U  StoreType{m,  S,  (02,  boxed  local  valid  72)) 
where  S((m,a))  =  (01,02) 

=  StoreType(m,  S,  ({m,  a),  boxed  local  valid  (ti,t2))) 


definition  of  Store  Type 


by  induction,  twice 


definition  of  Store  Type 


□ 


Lemma  3.  The  store  typing  of  a  single  value  and  type  is  unchanged  by  a  single  fresh  extension  of  the  store. 
That  is,  for  any  local  address  a'  such  that  (to,  a')  ^  dom(S) ,  and  for  any  storable  value  sv, 

StoreType{m. ,  S,  ( v ,  r))  =  StoreType(m,  S[{m,  a1)  <—  sx],  (v,  r)) 

provided  that  the  first  store  typing  function  is  defined. 

Proof.  The  proof  is  by  induction  of  the  structure  of  r. 

Base  Case:  Integers  Suppose  that  r  is  int.  Then  v  must  be  an  integer  i.  We  must  show  that 

StoreTypeim. ,  S,  (i,  int))  =  StoreType(m,  S[(m,  a)  <—  sx],  (i,  int)) 

This  equivalence  holds  trivially  from  the  definition  of  StoreType,  which  is  always  Ax.  _L  for  integers,  regardless 
of  the  store. 

Base  Case:  Invalid  Pointers  Suppose  that  r  is  boxed  local  invalid  t'  for  some  r'.  Then  v  must  be 
a  local  pointer  a.  We  must  show  that  for  any  storable  value  sv, 

StoreType(m,S,  (a,  boxed  local  invalid  t')) 

=  StoreType(m,  S[{m,  a1)  <—  sx],  (a,  boxed  local  invalid  t')) 

This  holds  trivially  from  the  definition  of  StoreType,  which  is  always  Ax.  _L  for  invalid  local  pointers,  regardless 
of  the  store.  The  case  for  invalid  global  pointers  is  analogous. 

Inductive  Cases:  Valid  Local  Pointers  Suppose  that  r  is  boxed  local  valid  t'  for  some  r'.  Then  v 
must  be  a  valid  focal  pointer  a  on  machine  to.  We  must  show  that 

StoreTypeim,  S,  (a, boxed  local  valid  t')) 

=  StoreType(m,  S[(m,  a')  <—  si>],  (a,  boxed  local  valid  t')) 

There  are  two  subcases,  depending  upon  whether  r'  is  or  is  not  a  pair. 
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Inductive  Subcase:  Valid  Local  Pointers  to  Non-Pairs  Suppose  that  r'  is  not  a  pair  type. 
From  the  definition  of  StoreType ,  if  StoreType(m,  S,  (a,  boxed  local  valid  t'))  is  defined  then  we  know  that 
(to,o)  £  dom(S).  Since  {m,a!)  ^  dom(S)  it  follows  that  a  ^  a' .  Then 


StoreTypelpn.,  S,  (a,  boxed  local  valid  t')) 

=  StoreType(m,  S,  (S((m,a)),Tr))  U  Ax.  _L  [( m,a )  <—  t'] 

=  StoreTypelpn.,  S[(m,a')  <—  si>],  (5((m,  a)),T'))  by  induction 

U  Ax’.  _L  [(m,a)  <—  r'] 

=  StoreTypelpn.,  S[(m,  a1)  <—  su],  (S[(to,  a')  <—  sv]((m,  a)),  t'))  since  a  ^  o' 

U  Ax\  _L  [(m,  a)  <—  r'] 

=  StoreTypelpn,  S{{m,  a!)  su],  (a,  boxed  local  valid  r')) 


Inductive  Subcase:  Valid  Local  Pointers  to  Pairs  Suppose  that  t'  is  (ti,T2)  for  some  t-\  and  r2. 

Then  S((m,  a})  must  be  (ai,  02)  for  some  pair  of  local  addresses  a\  and  02-  From  the  definition  of  StoreType, 
if  StoreType{m,  S,  (a,  boxed  local  valid  (n,  T2)))  is  defined  then  we  know  that  {(m,  a),  (m,  ai),  (?n,  02)}  C 
dom(S).  Since  ( m,a' )  £  dom(S)  it  follows  that  a'  is  not  equal  to  a,  01,  or  02-  Then 


StoreType(m,  S,  (a,  boxed  local  valid  (ti,T2))) 

=  Ax.  T  [{m,a)  <—  {t1,t2}} 

U  StoreType(in,  S,  (ai,  boxed  local  valid  ri)) 

U  StoreTypelpn,  S,  (0,2,  boxed  local  valid  T2)) 
where  S((m,a))  =  (01,02) 

=  Ax.  T  [(m,a)  <-  (r1,r2)] 

U  StoreType(m,  S[(m,  a)  <—  su],  (oi,  boxed  local  valid  ri)) 

U  StoreType(m,  S[(m,  a1)  <—  sx],  (02,  boxed  local  valid  T2)) 

where  S((m,a))  =  (01,02) 

=  Ax.  T  [(m,o)  <-  (ri,r2)] 

U  StoreTypelpn,  S{{m,  a!)  <—  sx],  (oi,  boxed  local  valid  ri)) 

U  StoreTypelpn,  S{{m,  a!)  sx],  (a2,  boxed  local  valid  r2)) 

where  S[(m,  o')  <—  sx]((m,o))  =  (ai,a2) 

=  StoreTypelpn,  S[{m,  a!)  <—  sx],  (a,  boxed  local  valid  (ti,t2))) 


definition  of  StoreType 


by  induction,  twice 


since  a'  0  {a,  an,  02} 


definition  of  StoreType 


Inductive  Cases:  Valid  Global  Pointers  Suppose  that  r  is  boxed  global  valid  t'  for  some  r'.  Then 
v  must  be  a  valid  global  pointer  ( mv,av ).  We  must  show  that 

StoreTypelpn ,  S ,  ((mv,av),  boxed  global  valid  r')) 

=  StoreTypelpn,  S[{m,  a!)  <—  su],  ((mv,av),  boxed  global  valid  r')) 

There  are  two  subcases,  depending  upon  whether  r'  is  or  is  not  a  pair. 


Inductive  Subcase:  Valid  Global  Pointers  to  Non-Pairs  Suppose  that  r'  is  not  a  pair  type. 
From  the  definition  of  StoreType,  if  StoreTypelpn,,  S,  ((mv,av),  boxed  global  valid  r'))  is  defined  then  we 
know  that  ( mv,av )  €  dom(S).  Since  ( m,a ')  dom(S)  it  follows  that  ( mv,av )  7^  (m,  o').  Then 
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StoreTypeim ,  5,  ((m„,  a„ 

),  boxed  global  valid  r ’)) 

=  StoreType{mv ,  S,  (S((mv,  a^,)),r,)  U  Ax.  _L  [(m„,  a„)  <—  r']) 

=  StoreType(mv,  S[{m,a') 

<-  s«],  ( S((mv,av)),T ')) 

by  induction 

U  Ax.  _L  <—  t' 

) 

=  StoreType{mv,  S[(m,a') 

<—  Sf],  (5[(m,  a7)  <-  su]((m„,  a„)),  r')) 

since  ( mv,av )  ^  ( m,a  ) 

U  Ax.  _L  <—  r' 

1 

=  StoreType(mv,  S[(m,a) 

<—  su],  (a„,  boxed  local  valid  t')) 

=  StoreTypeim,  S[{m,  a')  *■ 

—  su],  {(mv,av),  boxed  global  valid  t')) 

by  Lemma  2 

Inductive  Subcase:  Valid  Global  Pointers  to  Pairs  Suppose  that 

t'  is  (ti,t2)  for  some  iq 

and  r2.  Then  S((mv,av ))  must  be  (01,02)  for  some  pair  of  local  addresses  Oi  and  a2.  From  the  defini¬ 
tion  of  StoreType ,  if  StoreType{m,  S,  {(mv,av),  boxed  global  valid  (ti,t2)))  is  defined  then  we  know  that 
{(mv,  av),  (mv,  oi),  (mv,  a2)}  C  dom(S).  Since  (m,a')  £  dom(S)  it  follows  that  (m,  a')  is  not  equal  to 
(mv,av),  ( mv,a\ ),  or  (m„,a2).  Then 

StoreType{m,  S,  {{mv,  av),  boxed  global  valid  (ti,t2))) 

=  Ax.  JL  [(m„,o„)  <—  (t1,t2)] 

U  StoreType{m,  S,  {(mv,  Oi),  boxed  global  valid  iq)) 

U  Store Type(m,  S,  ((mv,  o2),  boxed  global  valid  t2)) 
where  S((mv,av))  =  (oi,o2) 

=  Ax.  T  [(m„,a„)  <— (ti,t2)] 

U  StoreType{m,  S[(m,a')  <—  sw],  ((m„,ai), boxed  global  valid  71)) 

U  StoreType(m,  S[(m,a)  <—  su],  {{mv,  a2),  boxed  global  valid  r2)) 
where  S((mv,av))  =  (oi,a2) 

=  Ax.  T  [(m„,a„)  <—  (t1,t2)] 

U  StoreType(mv ,  S[(m,a')  <—  su],  ((m„,  oi),  boxed  global  valid  iq)) 

U  StoreType{mv,  S[(m,  a1)  <—  su],  ((m„,  a2),  boxed  global  valid  r2)) 
where  S[(m,  a')  <—  sr>]((m„,  a,,))  =  (ai,a2) 

=  StoreType(m,  S[(m,a')  su],  ((mv,av),  boxed  global  valid  (ti,t2))) 


definition  of  StoreType 


by  induction,  twice 


since  (m,  a')  ^  dom(S) 


definition  of  StoreType 


Inductive  Case:  Pairs  Suppose  that  r  is  (ti,t2)  for  some  ti,t2.  Then  v  must  be  a  pair  (tq,u2).  We 
must  show  that 

StoreType{m,  S,  ({vi,v2),  (ti,t2)))  =  S,toreT?/pe(m,  a')  <-  su],  ((ui,u2),  (ri,r2))) 

We  can  show  inductively  that  each  component  of  the  pair  produces  an  identical  typing  function  in  the 
extended  store,  and  thus  the  typing  function  for  the  pair  as  a  whole  remains  unchanged  as  well.  Using  the 
definition  of  StoreType : 

StoreType(m,  S,  ((vi,v2),  (ti,t2))) 

=  (StoreType(m,  S,  (v\,ti)) 

U  StoreType(m,  S,  (u2,  r2))) 

=  (StoreType(m,  S[(m,  a1)  <—  su],  (tq,Ti))  by  induction,  twice 

U  StoreType(m,  S[(m,ar)  <—  su],  (u2,  r2))) 

=  StoreType(m,S[(m,a)  <-  av],  ((vi,  v2),  (n,  r2))) 

□ 
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Corollary  4.  The  store  typing  of  a  set  of  values  and  types  is  unchanged  by  a  single  fresh  extension  of  the 
store.  That  is,  for  any  local  address  a'  such  that  ( to,  a ')  dom(S),  and  for  any  storable  value  sv, 

StoreType(m,  S ,  U )  =  StoreType(m,  S[{m,  a1)  <—  sx],  U) 

provided  that  the  first  store  typing  function  is  defined. 

Proof.  Easily  derived  from  Lemma  3  by  induction  on  the  size  of  U.  O 

Corollary  5.  The  store  typing  of  a  set  of  values  and  types  is  unchanged  by  multiple  fresh  extensions  of  the 
store.  That  is,  for  any  vector  of  n  distinct  local  addresses  a'  such  that  (m,  a')  ^  dom(S ),  and  for  any  vector 
of  n  storable  values  svi, 

StoreType(m ,  S,  U)  =  StoreTypefm,  S[{m,  a[)  sv i, . . . ,  (to,  a'n)  <—  sun],  U) 

provided  that  the  first  store  typing  function  is  defined. 

Proof.  Easily  derived  from  Corollary  4  by  induction  on  n.  □ 

Lemma  6.  The  store  typing  function  for  a  set  of  values  and  types  is  at  least  as  defined  as  that  for  the  same 
set  with  one  type  replaced  by  a  subtype.  That  is,  for  any  types  r  and  t'  such  that  r  <  r', 

StoreType(m,  S,U  U  {(v,t)})  □  StoreType(m,  S,U  U  {(v,t')}) 

provided  that  the  first  store  typing  function  is  defined. 

Proof.  Proof  is  by  induction  on  the  structure  of  r. 

Base  Case:  Identical  Types  If  r  =  t'  the  result  is  trivial. 

Base  Case:  Valid  and  Invalid  Pointers  Suppose  that  r  is  a  local  pointer.  If  t  ^  t'  then  it  must  be 
the  case  that 

t  =  boxed  local  valid  tq 
A  t'  =  boxed  local  invalid  To 

A  v  =  a 

for  some  To  and  a.  However,  StoreType(m,  S,  (a,  boxed  local  invalid  To))  is  always  Xx.  _L,  so  we  have 

StoreTypefm ,  S',  t/  U  {(v,  boxed  local  valid  To)}) 

3  StoreType(m ,  S,  U  U  {Ax.  _L}) 

=  StoreTypefm ,  S,  U  U  {(v,  boxed  local  invalid  To)}) 

which  proves  the  result. 

Inductive  Case:  Pairs  Assume  that  t  =  (ti,T2).  Then  t'  =  (t},^)  and  v  =  (vx^vf).  Using  the 
definitions  of  StoreType  and  subtyping: 

StoreType{m ,  S,  U  U  {(c,t)})  where  t  <  t' 

=  StoreType(m,  S,U  U  {((vi,v2),  (ti,t2))})  where  (ti,t2)  <  (t{,t2) 

=  StoreType{m1  S,U  U  {(t>i,  Ti),  (u2,  t2)})  where  t\  <  t[  A  t2  <  Tj 

□  StoreType{m1  S,U  U  {(^i,  r{),  (u2,  t2)})  where  r2  <  t ^  by  induction 

□  StoreType(m,  S,  U  U  {(xi,  t{),  (i>2,  rf)})  by  induction 

=  StoreType(m,  S,  U  U  {((xi,v2),  (t[,t'2))}) 

□ 
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Lemma  7.  Uniformity  is  retained  following  local  replacement  of  a  single  non-pair  by  a  new  value  of  the 
same  type.  That  is,  if  we  define  U  =  Uq  U  {(sv,  t),  (a,  boxed  local  valid  r)}  where  r  is  not  a  pair  type, 
then 

Uniform(StoreType(m,  S,U))  =>  Uniform(StoreType(m.,  S[(m,a)  <— sv],?7)) 
provided  that  the  first  store  typing  function  is  defined. 

Proof.  It  suffices  to  show  that  Uniform(StoreType(m,  S,U))  implies  that 

V(vo,  tq)  £  U  .  StoreType(m. ,  S,  U )  3  StoreType(m,  S[(m,  a)  <—  sv],  (vo,  to}) 
from  which  it  follows  that 

StoreType(m,  S,  U ) 

□  | _ |  StoreType(m,  S[{m,  a)  <—  sv],(vo,  to)) 

(v0,t0)£U 

=  StoreType(m ,  S[(m,  a)  <—  sv],  U) 

Then  since  Uniform(StoreType(m,  S,U))  holds  and  StoreType(m,  S,U)  □  StoreType(m,  S[(m,  a)  <—  sw],I7), 
we  know  that  Uniform(StoreType(m,  S[(m,  a)  <—  su],  U)).  The  proof  is  by  induction  on  the  structure  of  tq. 

Base  Case:  tq  =  int  Then  Uniform(StoreType(m,  S,U))  implies  that  vq  is  an  integer. 

StoreType(m,  S,  U ) 

3  Xx.  T 

=  StoreType(m,  S[(m,  a)  <—  su],  {vq,  int))  definition  of  StoreType 

Inductive  Cases:  r0  =  boxed  local  valid  t' 

StoreType(m ,  S,  U)  is  defined 

==>  Vo  is  a  local  address  and  S((m,v o})  is  defined  since  (vo,to)  £  U 

There  are  three  subcases,  depending  upon  whether  vq  is  or  is  not  the  updated  address,  and  whether  t' 
is  or  is  not  a  pair. 


Inductive  Subcase:  vq  =  a  Since  Uniform(StoreType(m,  S,  U))  is  true,  we  know  that  r  =  t'  from  the 
definition  of  uniformity.  We  reason  as  follows: 


StoreType(m ,  S,  Uq  U  {(sv,  t),  (a,  boxed  local  valid  r)}) 
3  Ax.  _L  [(m,a)  <—  r]  U  StoreType(m,  S,Uo  U{(su,r)}) 

3  Ax’.  T  [( m,a )  r]  U  StoreType(m,  S[(m,a)  <—  sv],  (sv,t)) 
=  StoreType(m,  S[(m,a)  <—  su],  (a,  boxed  local  valid  r)) 

=  StoreType(m,  S[(m,a)  <—  sv],  (uq,  boxed  local  valid  r')) 


definition  of  StoreType 
by  induction 
definition  of  StoreType 
since  Vo  =  a  and  r  =  t' 
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Inductive  Subcase:  xq  ^  a  and  t'  ^  (ti,T2) 


StoreType(m ,  S ,  [/) 

=  StoreType(m,  S,U  U  {(xo,  boxed  local  valid  r/)}) 

=  Ax.  _L  [(to,  vq)  *—  t'] 

U  StoreType{m1  S,  U  U  {(S((m,  vq)),  t7)}) 

□  Ax.  _L  [(to,  Vq)  <—  t'] 

U  StoreType(m,  S[(m.,  a)  <—  sx],  (S((m.,  Vq}),  t')) 

=  Ax.  _L  [(to,  vg)  <—  t'] 

U  StoreType(m,  S[(m,  a)  <—  sx],  (S[(m,  a)  <—  sx]((to,x o)),t7)) 
=  StoreType(m,  S[(m,a)  sx],  (xo,  boxed  local  valid  r7)) 


since  (vo,  boxed  local  valid  r1)  £  Uo 
definition  of  StoreType 

by  induction 

since  vo  ^  a 

definition  of  StoreType 


Inductive  Subcase:  v0  ^  a  and  r'  =  (ri,r2) 

StoreType(m,  S,  U) 

=  StoreType(m,  S,U  U  {(xo,  boxed  local  valid  (ti,T2))}) 

=  Ax.J,  [(to,  v0)  <-  (ri,r2)] 

U  StoreType(m,  S,U  U{(ai,  boxed  local  valid  ly)}) 

U  StoreType(m,  S,U  U{(a2,  boxed  local  valid  12)}) 
where  S((m,v 0))  =  (01,02) 

□  Ax.  _L  [(m,v0)  <—  (t1,t2)] 

U  StoreTypeim,  S[{m,  a)  <—  sx],  (ai,  boxed  local  valid  ri)) 

U  StoreType(m,  S[{m,  a)  <—  sx],  (a2,  boxed  local  valid  r2)) 

where  S((m,v 0))  =  (01,02) 

=  Ax.  -L  [(to,  x0)  <—  ('r1,r2)] 

U  StoreType(m,  S[(m,  a)  <—  sx],  (ai,  boxed  local  valid  ri)) 

U  StoreType(m,  S[{m,  a)  <—  sx],  (a2,  boxed  local  valid  r2)) 

where  S[{m,a)  <—  sx]((m,  Xo))  =  (01,02) 

=  StoreType(m,  S[(m,  a)  <—  sx],  (vq,  boxed  local  valid  (ti,t2))) 


since  (vo,  boxed  local  valid  t')  £  Uo 
definition  of  StoreType 


by  induction,  twice 


since  (to,  vq)  ^  (to,  a) 


definition  of  StoreType 


Inductive  Cases:  r0  =  boxed  global  valid  r'  There  are  three  subcases  paralleling  the  three  subcases 
for  local  pointers. 


Inductive  Subcase:  Vo  =  ( to.,o )  Since  Uniform(StoreType(m.,  S,U))  is  true,  we  know  that  r  =  r' 
from  the  definition  of  uniformity,  and  therefore  that  t'  ^  (ti,t2).  We  reason  as  follows: 


StoreTypeim,  S,  Uq  U  {(sx,  t),  (a,  boxed  local  valid  r)}) 

□  Ax.  _L  [(to,  a)  <—  t]  U  StoreType(m,  S,Uo  U  {(sv,t)}) 

□  Ax.  _L  [(to,o)  *—  t]  U  StoreType{m,  S[(m,  a)  <—  sx],  ( sx,r )) 

=  StoreType(m,  S[(m,  a)  <—  sx],  ((to,  a),  boxed  global  valid  r)) 
=  StoreType{m,  S[(m,  a)  <—  sx],  (xq,  boxed  global  valid  t')) 


definition  of  StoreType 
by  induction 
definition  of  StoreType 
since  vo  =  (to,  a)  and  r  =  t' 
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Inductive  Subcase:  vg  =  ( m',a ')  ^  (to, a)  and  r'  ^  (ti,T2) 


StoreType(m. ,  S',  t/) 

=  StoreType(m.,  S,U  U{(xo,  boxed  global  valid  t/)}) 

□  Ax.  T  [xo  <—  t'\ 

U  StoreType(m' ,  S,  (S(vo),t’)) 

□  Ax.  T  [xo  <—  t'\ 

U  StoreType{rn! , S[(m,a)  <—  sv],(S(vo),t')) 

=  Ax.  _L  [xo  <—  t'] 

U  StoreType(in' ,  S[(m,  a)  <—  sx],(S[(to,  a)  <—  sx](xo),  t')) 
=  StoreType{m. ,  S[(m,  a)  <—  sx],  (xo,  boxed  global  valid  t')) 


since  (xo,  boxed  global  valid  r)  £  Uo 
definition  of  StoreType 

by  induction 

since  vo  ^  (m,  a) 

definition  of  StoreType 


Inductive  Subcase:  x0  =  ( to.',  a '}  ^  ( to,  a )  and  t'  =  (ti,t2) 


StoreType (to.,  S,  U) 

=  StoreType(m.,  S,U  U{(xo,  boxed  global  valid  (ti,T2))}) 

=  Ax.  _L  [x0  <-  (ri,r2)] 

U  StoreType(m,  S,U  U  {((m/,  ai),  boxed  global  valid  ti)}) 

U  StoreType(m.,  S,U  U  {((mf,  a2),  boxed  global  valid  r2)}) 
where  S(xo)  =  (01,02) 

□  Ax.  i  [x0  <—  (ri, r2)] 

U  StoreType(m,  S[(m,  a)  <—  sx],  ((m\  oi),  boxed  global  valid  ti)) 

U  StoreType(m,  S[(m,  a)  <—  sx],  ((mf ,  a2),  boxed  global  valid  r2)) 

where  S(xo)  =  (01,02) 

=  Ax.  _L  [x0  <—  (ti,t2)] 

U  StoreType(m.,  S[(m,  a)  <—  sx],  ((to/,  a\),  boxed  global  valid  ti)) 

U  StoreType(m.,  S[(m,  a)  *—  sx],  ((to',  o2),  boxed  global  valid  r2)) 

where  S[(m,a)  <—  sx](xo)  =  (01,02) 

=  StoreType(m.,  S[(m,  a)  sx],  (xq,  boxed  global  valid  (ti,72))) 


since  (x0,r0)  G  U0 
definition  of  StoreType 


by  induction,  twice 


since  vq  ^  (to,  a) 


definition  of  StoreType 


Base  Case:  To  =  boxed  local  invalid  r;  Then  Uniform(StoreType(m,  S,U))  implies  that  Vg  is  a  local 
address. 

StoreType(m ,  S,  U) 

□  Ax.  1 

=  StoreType(m,  S[(m,  a)  <—  sx],  (x,  boxed  local  invalid  t'))  definition  of  StoreType 

Base  Case:  Tg  =  boxed  global  invalid  r'  Then  Uniform(StoreType(m,  S,  U))  implies  that  vg  is  a  global 
address. 

StoreType{m, ,  S,  U) 

□  Ax.  T 

=  StoreType(m,  S[(m,  a)  <—  sx],  (x,  boxed  global  invalid  t))  definition  of  StoreType 
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Inductive  Case:  r0  =  (ti,t2)  Then  Uniform(StoreType(m,  S,U))  implies  that  vq  =  (fi,u2).  We  reason 


as  follows: 

StoreType(m ,  S,  U ) 

=  StoreType(m,S,U  U  tx),  (v2,  t2)}) 

definition  of  StoreType 

□  StoreTypefm,  S[(m,a)  < 

SU],  (t>l,Tl)) 

by  induction,  twice 

U  StoreType(m,  S[{m, 

a)  <-  su],  (v2,t2)) 

=  StoreTypefm,  S[(m,a)  < 

1-  su],((ui,t;2),(Ti,T2))) 

definition  of  StoreType 

Corollary  8.  Uniformity  is  retained  following  local  replacement  of  several  non-pairs  by  new  values  of  the 
same  types.  That  is,  if  we  define 

U  =  Uq  U  (ai,  boxed  local  valid  Ti), . . . ,  ( svn,Tn ),  (an,  boxed  local  valid  rn)} 

where  all  ai  are  distinct  and  all  Tj  7^  (t,  t'),  then 

Uniform(StoreType(m,  S,  U))  =>  Uniform(StoreType(m,  S[(m,  ai)  <—  svi, . . . ,  (to,  an)  <—  sun],  U)) 
provided  that  the  first  store  typing  function  is  defined. 

Proof.  Easily  derived  from  Lemma  7  by  induction  on  n.  □ 

Lemma  9.  A  robust  value  and  type  induces  the  same  store  typing  function  on  any  machine.  That  is,  if 
robust(r)  is  true  then 

StoreType(mo ,  S',  ( v ,  r))  =  StoreType(rn\ ,  S,  ( v ,  r)) 

provided  that  the  first  store  typing  function  is  defined. 

Proof.  The  proof  is  by  induction  on  the  structure  of  r. 

Base  Case:  r  =  int  Then  v  =  i  for  some  integer  i. 

StoreType(mo ,  S,  (*,  int)) 

=  Xx.  _L 

=  StoreType{m\1  S,  (i,  int)) 

Base  Case:  r  =  boxed  local  invalid  tq  Then  v  =  a  for  some  address  a. 

StoreType{m.Q ,  S ,  (a,  boxed  local  invalid  To)) 

=  Xx.  T 

=  StoreType(m.\:  S,  (a,  boxed  local  invalid  To)) 

Base  Case:  r  =  boxed  global  invalid  tq  Then  v  =  g  for  some  global  address  g. 

StoreType{rrif)1  S,  (<?,  boxed  local  invalid  r0)) 

=  Xx.  ± 

=  StoreType(nii,  S,  (g,  boxed  local  invalid  To)) 

Base  Case:  r  =  boxed  local  valid  tq  Then  robust(r)  does  not  hold,  contradicting  the  lemma  premise. 
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Base  Case:  r  =  boxed  global  valid  tq  Then  v  =  (in,  a)  for  some  machine  to  and  address  a. 


StoreType(mo,  S,  ((to,  a),  boxed  global  valid  r0)) 
StoreType(m,  S,  (a,  boxed  local  valid  To)) 

=  StoreType(mi,  S,  ((m,  a),  boxed  global  valid  To)) 

Inductive  Case:  t  =  (ti,T2)  Then  v  =  (v\,v2}  for  some  values  v\  and  v2. 

StoreType(m0,S,  {{vi,v2),  (ti,t2))) 

=  StoreType(m0,S,(v1,T1))  U  StoreType(m0,  S,  (v2,r2)) 

=  StoreType(m\,  S,  (v\,Ti))  U  StoreType(m\,  S,  (v2,t2)) 

=  StoreType(mi,S,  {(vi,v2),  (n,  t2))) 


by  Lemma  2 
by  Lemma  2 


definition  of  StoreType 
by  induction,  twice 


□ 


Lemma  10.  Uniformity  is  retained  following  global  replacement  of  a  single  robust  non-pair  by  a  new  value 
of  the  same  type.  That  is,  if  we  define  U  =  Uq  U  {(sw,  t),  ( g ,  boxed  global  valid  t)}  where  t  is  not  a  pair 
type,  and  further  require  that  robust(r)  be  true,  then 

Uniform(StoreType(m,  S,  U))  =>  Uniform(StoreType(m ,  <—  su],  U )) 

provided  that  the  first  store  typing  function  is  defined. 

Proof.  As  in  the  case  of  local  assignment,  it  suffices  to  show  that  Uniform(StoreType(m,  S,  U))  and  robust(r) 
implies  that 

V(v0,To)  £  U  .  StoreType(m,S,U)  U  StoreType(m,S{g  sv\,(vq,tq)) 
from  which  it  follows  that 

StoreType(m,  S,  U ) 

□  LJ  StoreType(m,  S[g  <-  sv],  (v0,t0)) 

(vo,ro)eu 

=  StoreType(m,  S[g  <—  sr>],  U) 

Then  since  Uniform(StoreType(m,  S,U))  holds  and  StoreType(m,  S,U)  □  StoreType(m,  S[g  <—  sv],U),  we 
know  that  Uniform(StoreType(m ,  S[g  <—  su],  U)).  The  proof  is  by  induction  on  the  structure  of  To- 

Base  Case:  tq  =  int  Then  Uniform(StoreType(m,  S,U))  implies  that  Vq  is  an  integer. 

StoreType(m,  S,  U ) 

□  Xx.  T 

=  StoreType(m ,  S[g  sc],  ( vg ,  int)) 


definition  of  StoreType 


Inductive  Cases:  tq  =  boxed  local  valid  t' 


StoreType(m,  S,U)  is  defined 

Vq  is  a  local  address  and  S((m,v 0))  is  defined 


since  (vq,to)  G  U 


There  are  three  subcases,  depending  upon  whether  (m,v 0)  is  or  is  not  the  updated  address,  and  whether 
t'  is  or  is  not  a  pair. 
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Inductive  Subcase:  (m,  v o)  =  g  Since  Uniform{StoreType{m,  S,U))  is  true,  we  know  that  r  =  r7 
from  the  definition  of  uniformity.  We  reason  as  follows: 


StoreType(m ,  S,  Uq  U  {(sv,  t),  (g,  boxed  global  valid  r)}) 

□  Aar.--.4--  [g  <—  t]  U  StoreType(m,  S,Uo  U  {(sv,t)}) 

□  Ax.  -L  [g  <—  r]  U  StoreType(m ,  S[<?  <—  sv],  (sv,t)) 

=  Ax.  4.  [(to,  Vo)  r]  U  StoreType{m.,  S[g  sv],  ( sv,r )) 

=  StoreType{m,  S[g  <—  sv],  (vo,  boxed  local  valid  r)) 

=  StoreType(m,  S[g  e—  sv],  (vo,  boxed  local  valid  t7)) 


definition  of  StoreType 
by  induction 
since  (m,  vo)  =  g 
definition  of  StoreType 
since  r  =  t' 


Inductive  Subcase:  (m,v o)  4  and  t'  4  (ti,T2) 
StoreType(m,  S,  U) 

=  StoreType(m ,  S',  U  U  {(vo,  boxed  local  valid  r7)}) 

=  Aar.  _L  [(to,  i>o)  <—  r7] 

U  StoreType{m,  S,U  U  {(S((m,  no)),  t/)}) 

□  Aar.  4-  [(to,  vq)  <—  r7] 

U  StoreType(m,  S[g  <—  sv],  (S((to,  r>o)),  4)) 

=  Aar.  _L  [(to,  Vq)  <—  r7] 

U  StoreType(m,  S[g  sv],  (S[g  <—  sv]((to,  Vq )),  t7)) 
=  StoreType(m ,  S[<?  <—  sv],  (z)q,  boxed  local  valid  r7)) 


since  (vo,  boxed  local  valid  r7}  G  [To 
definition  of  StoreType 

by  induction 

since  (m,  vo)  4  g 

definition  of  StoreType 


Inductive  Subcase:  (to,  v o)  4  and  r7  =  (ti,T2) 
StoreType(m,  S,  U) 

=  StoreType(m,  S,U  U{(vo,  boxed  local  valid  (t1,T2))}) 

=  Ax.  _L  [(to,  v0)  <- (ri,r2)] 

U  StoreType(m,  S,U  U{(ai,  boxed  local  valid  ti)}) 

U  StoreType(m,  S,U  U  {(<22,  boxed  local  valid  12)}) 
where  S((to,  v 0))  =  (01,02) 

□  Ax,.J_  [(to,  v0)  <-  (r1,r2)] 

U  StoreTypeim,  S[g  <—  sv],  (01,  boxed  local  valid  ri)) 
U  StoreType(m ,  S[g  <—  sv],  (02,  boxed  local  valid  T2)) 
where  S((to,  v 0))  =  (01,02) 

=  Ax.  J_  [(to,  v0)  <-  (ri,r2)] 

U  StoreType(m,  S[g  <—  sv],  (oi,  boxed  local  valid  ri)) 
U  StoreType(m ,  S[g  <—  sv],  (02,  boxed  local  valid  T2)) 
where  S[g  <—  sv]((to,  Vo))  =  (01,02) 

=  StoreTypeim,,  S[g  sv],  (vq,  boxed  local  valid  (ti,72))) 


since  (vo, boxed  local  valid  (ti,T2))  G  Uo 
definition  of  StoreType 


by  induction,  twice 


since  (to,  vo)  4  5 


definition  of  StoreType 


Inductive  Cases:  tq  =  boxed  global  valid  r7  There  are  three  subcases  paralleling  the  three  subcases 
for  local  pointers. 
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Inductive  Subcase:  vg  =  (to7 ,  a'}  =  g  Since  Uniform(StoreType(m,  S,  U))  is  true,  we  know  that  r  =  r7 
from  the  definition  of  uniformity.  We  reason  as  follows: 


Store  Type{m.,  S,Ug  U  {(si>,t),  (g,  boxed  global  valid  r)}) 

□  Ax.  J_  [g  <—  r]  U  StoreType{m ,  S,  Ug  U  {(sx, t)}) 

□  Xx.  J_  [g  <—  r]  U  StoreType(m,  S[g  <—  su],  ( sv,t )) 

=  Xx.  -L  [g  ■*—  r]  U  StoreType(m' ,  S[g  <—  su],  (sx,r)) 

=  Xx.  _L  [g  r]  U  St.oreType(m' ,  %  4-  su],  (S[c/  <-  su](g),  r)) 

=  Ax.  _L  [(m7,a7)  <—  t]  U  StoreType(m' ,  S[g  4—  sx],  (S[<?  <—  su](g),r)) 
=  Store Type{m. ,  S[g  <—  su],  ((m7,  a7),  boxed  global  valid  r)) 

=  Store Type{m. ,  S[g  4—  su],  (i>o,  boxed  global  valid  r7)) 


definition  of  StoreType 

by  induction 

by  Lemma  9 

since  S[g  <—  sn](g)  =  sv 

since  S[g  <—  su](g)  =  sv 

definition  of  StoreType 

since  Vo  =  (m! ,  a  )  and  t  =  t' 


Inductive  Subcase:  vg  =  ( m7,a ')  y7  5  and  t7  y7  (ti,T2) 
StoreType(m. ,  S',  17) 

=  StoreType(m,  S,U  U  {(no,  boxed  global  valid  r7)}) 

=  Store  Type(mn ,  S,  17) 

U  Ax.  _L  [uo  <—  t7]  U  StoreType(m' ,  S,  (S(vq),t')) 

Xx.  _L  [uq  4—  t7]  U  StoreType(m' ,  S ,  (S(uo),t7)) 

Ax.  _L  [uo  <—  r7] 

U  StoreType(m' ,  S[g  <—  sv],{S(v o),r7)) 

=  Ax.  _L  [uo  <—  r7] 

U  StoreType(m! ,  S[g  4-  su],  (S[g  4-  su](u0),  r')) 

=  StoreType(m ,  S[g  <—  sx],  (uq,  boxed  global  valid  r7)) 


since  (no,  boxed  global  valid  r7}  €  17o 
definition  of  StoreType 

by  induction 
since  vo  yf  g 
definition  of  StoreType 


Inductive  Subcase:  vg  =  ( m',a :')  y7  g  and  r7  =  (7-1,72) 


StoreType(m ,  S,  17) 

=  StoreType(m,  S,U  U  {(no,  boxed  global  valid  (ti,T2))}) 

=  Ax.  J_  [v0  <-  (ti,t2)] 

U  StoreType(m ,  S,  17  U  {((to7,  ai),  boxed  global  valid  ri)}) 

U  StoreType(m ,  S,  17  U  {((to7,  <22),  boxed  global  valid  T2)}) 
where  S(uo)  =  (01,02) 

□  Ax.  _L  [u0  4—  (r1,r2)] 

U  StoreType(m,  S[g  4—  su],  ((to7,  ai),  boxed  global  valid  ri)) 

U  StoreType(m,  S[g  4—  st;],  ((to7,  02),  boxed  global  valid  T2)) 

where  S(vo)  =  (01,02) 

=  Ax.  ±  [u0  4—  (ri,r2)] 

U  StoreType(m,  S{g  <—  su],  ((to7,  ai) ,  boxed  global  valid  ri)) 

U  StoreType(m,  S[g  4—  si;],  ((to7,  02) ,  boxed  global  valid  T2)) 

where  S[g  4—  su](t>o)  =  (01,02) 

=  StoreType(m,  S[g  <—  su],  (vg,  boxed  global  valid  (ti,T2))) 


since  (vo,to)  €  Uo 
definition  of  StoreType 


by  induction,  twice 


since  Vo  y^  g 


definition  of  StoreType 
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Base  Case:  To  =  boxed  local  invalid  t7  Then  Uniform(StoreType(m,  S,U))  implies  that  Vo  is  a  local 
address. 

StoreType(m ,  S ,  U) 

□  Xx.  _L 

=  StoreType(m,  S[g  <—  sw],  (v,  boxed  local  invalid  t7))  definition  of  StoreType 

Base  Case:  To  =  boxed  global  invalid  t'  Then  Uniform(StoreType(m,  S,  U ))  implies  that  vq  is  a  global 
address. 

StoreType(m ,  S,  U) 

□  A.t.  T 

=  StoreType(m,  S[g  <—  sv],  (v,  boxed  global  invalid  t7))  definition  of  StoreType 

Inductive  Case:  t0  =  (ti,t2)  Then  Uniform(StoreType(m,  S,U))  implies  that  no  =  (i>i,b2).  We  reason 
as  follows: 

StoreType{m7  S,  U ) 

=  StoreType(m. ,  S',  U  U  {(ifi,  Tj),  (b2,  t2)})  definition  of  StoreType 

□  StoreType(m,  S[g  <—  sn],  (i>i,  ti))  U  StoreType{m.7  S[g  <—  sn],  (n2,  t2))  by  induction,  twice 

=  StoreType(m,  S[(j(  <—  sn],  ((vi,  n2),  (ti,t2)))  definition  of  StoreType 

□ 

Corollary  11.  Uniformity  is  retained  following  global  replacement  of  several  robust  non-pairs  by  a  new 
values  of  the  same  types.  That  is,  if  we  define 

U  =  U0  U  {(sui,  Tl),  (gi,  boxed  global  valid  Ti), . . . ,  (svn,Tn),  (gn,  boxed  global  valid  r„)} 
where  all  gi  are  distinct,  all  Tj  (t,  t7),  and  all  robust(ri)  are  true,  then 

Uniform(StoreType(m,  S,  [/))  =>  Uniform(StoreType(rn,  S[i?i  <—  sni, . ..  ,gn  <—  sn„],  U)) 
provided  that  the  first  store  typing  function  is  defined. 

Proof.  Easily  derived  from  Lemma  10  by  induction  on  n.  O 

Lemma  12.  The  store  typing  function  for  a  valid  local  pointer  is  at  least  as  defined  as  that  for  the  referenced 
value.  That  is, 

Store  Type(m,  S,  (a,  boxed  local  valid  t))  □  StoreType{m,  S,  (Value(S,  (m,a)),T)) 

provided  that  the  first  store  typing  function  is  defined. 

Proof.  The  proof  is  by  induction  on  the  structure  of  t. 

Base  Case:  Non-Pairs  Suppose  that  t  is  not  a  pair  type.  Then  S((m,a))  cannot  be  a  pair  of  local 
addresses.  So 

StoreType(m ,  S,  (a,  boxed  local  valid  t)) 

=  StoreType(m,  S,  (S ((m,  a)) ,  t))  U  Xx.  J_  [(to,  a)  <—  t\  definition  of  StoreType 

U  StoreType(m,  S,  (5((to,  a)),  t)) 

=  StoreType{m ,  S,  (  Value(S ,  (to,  a)),  t))  definition  of  Vafue 
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Inductive  Case:  Pairs  Suppose  that  r  is  (ti,T2)  for  some  t\  and  r2.  Then  S((m,a))  must  be  (<11,0,2) 
for  some  a\  and  02-  So 


StoreType(m,  S,  (a,  boxed  local  valid  (ti,t2))) 

=  Ax.  _L  \(m,a)  <—  (ti,t2)] 

U  StoreType(m,  S,  (ai,  boxed  local  valid  ti)) 

U  StoreType(m,  S,  (a2,  boxed  local  valid  r2)) 

□  StoreType(m,  S,  (ai, boxed  local  valid  ti)) 

U  StoreType(m,  S,  (a2,  boxed  local  valid  r2)) 

□  StoreType(m,  S,  ( Value(S,  (to,  a±)),  ti)) 

U  StoreType(m,  S,  ( Value(S,  (m,  02)),  t2)) 

=  StoreType(m,S,((Value(S,(m,ai)),  Value(S,  (m,  a2))),  (ti,  t2))) 
=  StoreType(m,  S,  ( Value(S,  (to,  a)),  (ti,  r2))) 


definition  of  StoreType 


by  induction,  twice 

definition  of  StoreType 
definition  of  Value 

□ 


Corollary  13.  Uniformity  of  a  set  of  values  and  types  is  preserved  across  dereferencing  of  a  valid  local 
pointer.  That  is, 

Uniform(StoreType(m,  S,U  U  {(a,  boxed  local  valid  r)})) 

=>  Uniform(StoreType(m ,  S,U  U  {( Value(S,  (to,  a)),  r)})) 

provided  that  the  first  store  typing  function  is  defined. 

Proof.  Easily  derived  from  Lemma  12  by  induction  on  the  size  of  U .  O 

Lemma  14.  The  store  typing  function  for  a  valid  global  pointer  is  at  least  as  defined  as  that  for  the 
referenced  value  with  type  popping.  That  is, 

StoreType(mo,  S,  ((to,  a),  boxed  global  valid  r))  □  StoreType(mo,  S,  (Value(S,  (m,a)),pop(T))) 

provided  that  the  first  store  typing  function  is  defined. 

Proof.  The  proof  is  by  induction  on  the  structure  of  r. 

Base  Case:  Integers  Suppose  that  r  is  int.  Then  S((m,a))  must  be  some  integer.  So 

StoreType(mo,  S,  ((m,  a),  boxed  global  valid  int)) 

□  Ax.  _L 

=  StoreType(mo,  S,  (S((m,  a)),  int))  definition  of  StoreType 

=  StoreType(mo ,  S,  (  Value(S ,  (to,  a)),  int))  definition  of  Value 

—  StoreType(mo,  S,  (Value(S,  (m,a)),  pop(int)))  definition  of  pop 

Base  Case:  Invalid  Pointers  Suppose  that  r  is  boxed  u>  invalid  t'  for  some  lo  and  t' .  Then  S((m,a)) 
must  be  an  invalid  w  pointer.  So 

StoreType(mo,  S,  ((to,  a),  boxed  global  valid  boxed  w  invalid  t')) 

□  Ax.  T 

=  StoreType(mo,  S,  (S((m,  a)),  boxed  ui  invalid  t'))  definition  of  Value 

=  StoreType(niQ,  S,  (  Value(S,  (to,  a)),  boxed  lo  invalid  t'))  definition  of  Value 

=  StoreType(mo,  S,  (  Value(S,  (to,  a)),pop( boxed  u>  invalid  t')))  definition  of  pop 
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Base  Case:  Local  Pointers  Suppose  that  r  is  boxed  local  p  t'  for  some  p  and  r'.  Then  S({m,a))  must 
be  a  p  local  pointer.  So 

Store Type{rriQ1  S,  ((to,  a),  boxed  global  valid  boxed  local  p  t')) 

□  Aar.  ± 

=  Store Type(mo,  S,  (S((m.,  a)),  boxed  local  invalid  r7))  definition  of  Value 

=  StoreType(mo,  S,  (  Value(S,  (to.,  a)),  boxed  local  invalid  t'))  definition  of  Value 

=  StoreType(mo,  S,  ( Valuers,  (to,  a)),pop( boxed  local  p  r7)))  definition  of  pop 

Note  that  the  preceding  two  derivations  are  equivalent  in  the  overlapping  case  where  r  is  both  local  and 
invalid. 


Base  Case:  Global  Pointers  Suppose  that  r  is  boxed  global  valid  t'  for  some  t' .  Then  S((m,a)) 
must  be  a  valid  global  pointer.  So 


StoreType(rriQ ,  S ,  ((to,  a),  boxed  global  valid  boxed  global  valid  t')) 
=  StoreType(m,  S,  (S((m,a)),  boxed  global  valid  t')) 

U  Ax.  _L  [( to,  a )  boxed  global  valid  r7] 

□  StoreType(m.,  S,  (S((m,a)),  boxed  global  valid  t')) 

=  StoreType(mo,  S,  (S((m,a)),  boxed  global  valid  r7)) 

=  StoreType(mo ,  S,  ( Value(S,  (m,  a)),  boxed  global  valid  r')) 

=  StoreType(mo,  S,  (Value(S,  {m,  a)) ,  pop(boxed  global  valid  t7))) 


definition  of  Store  Type 


by  Lemma  9 
definition  of  Value 
definition  of  pop 


Inductive  Case:  Pairs  Suppose  that  r  is  (ti,T2)  for  some  ti  and  r^.  Then  S({m,a})  must  be  (01,02) 
for  some  ai  and  02-  So 


StoreType(mo,  S,  ((m,  a),  boxed  global  valid  (ti,T2))) 

=  Ax.  _L  [(m,  o)  < —  (t 1 ,  T2)]  definition  of  StoreType 

U  StoreType(mo,  S,  ((m,  oi),  boxed  global  valid  ti)) 

U  StoreType(mo,  S ,  {(m,a 2),  boxed  global  valid  72)) 

□  StoreType(mo,  S,  ((to,  oi),  boxed  global  valid  ri)) 

U  StoreType(mo,  S,  ((771,02),  boxed  global  valid  r2)) 

□  StoreType(mo ,  5)  (  Value(S,  (to,  Oi)),pop(ri)))  by  induction,  twice 

U  StoreType(mo,  S,  ( Value(S ,  (to,  a^)) , pop{r2))) 

=  StoreType(mo ,  5,  ((  Value{S ,  (to,  Oi)),  Value(S,  (to.,  02))),  {pop(ji) , popfa))))  definition  of  StoreType 

=  StoreType(mo ,  5,  (  Value(S,  (to,  a)),  (popfa) ,  popfo))))  definition  of  Vafae 

=  StoreType(mo ,  5,  (  Value{S,  (to,  a)) ,  pop((ri ,  T2))))  definition  of  pop 

□ 


Lemma  15.  The  store  typing  function  for  a  valid  global  pointer  is  at  least  as  defined  as  that  for  the 
referenced  value  with  value  widening  and  type  expansion.  That  is, 

StoreType(mo,  S,  ((to,  a),  boxed  global  valid  r)) 

□  StoreType(mo ,  5,  ( WideValue(S ,  (to,  a)),  expand(r))) 

provided  that  the  first  store  typing  function  is  defined. 

Proof.  There  are  two  cases,  depending  upon  whether  r  is  or  is  not  a  local  pointer. 
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f  (/  • LeafTypes(n ))  if  t  =  (n,  r2) 
LeafTypes{r)  =  <  U  (\  -LeafTypes(T2)) 

I  {r}  otherwise 


Figure  19:  Auxiliary  function  for  leaf  type  enumeration. 


Local  Pointers  Suppose  that  r  is  boxed  local  p  t'  for  some  p  and  t' .  Then  S((m,a})  must  be  some 
local  pointer.  Therefore, 

StoreType(mo,  S',  ((to,  a),  boxed  global  valid  boxed  local  p  t')) 

=  StoreType{m1  S,  (S((m,  a)),  boxed  local  p  t'))  definition  of  StoreType 

=  U  Xx.  _L  [(to,  a)  «—  boxed  local  p  t'\ 

□  StoreType(m,  S,  (S((m,  a)),  boxed  local  p  t')) 

=  StoreType(mo ,  S,  ((m,  S((to,  a))),  boxed  global  p  r'))  by  Lemma  2 

=  StoreType(m o,  5,  (  Wide  Value(S,  (to,  a)),  e:rpand(boxed  local  p  t')))  definition  of  WideValue,  expand 

All  Other  Types  Suppose  that  r  is  int,  or  boxed  global  p  r'  for  some  p  and  r',  or  for  some 

T\  and  r 2 .  Then  from  the  definitions  of  expand  and  pop  we  know  that  expand{r)  =  pop(r).  Furthermore, 
^((to,  a))  cannot  be  a  local  pointer,  which  implies  that  Value(S,  ( m ,  a))  =  Wide  Value(S,  (to,  a)).  Therefore, 

StoreType(mo,  S,  ((to,  a),  boxed  global  valid  r)) 

□  StoreType(rriQ ,  S',  (  Valuers,  (to,  a)),pop(r )))  by  Lemma  14 

=  StoreType(mo ,  S,  ( FLide  Value(S,  (to,  a)),  expander))) 


O 

Corollary  16.  Uniformity  of  a  set  of  values  and  types  is  preserved  across  dereferencing  of  a  valid  global 
pointer  with  value  widening  and  type  expansion.  That  is, 

Uniform(StoreType(nio,  S,U  U{(p,  boxed  global  valid  r)})) 

==>  Uniform(StoreType(nio ,  S,  [/  U  {( Wide  Valuers,  g),  expander))})) 

provided  that  the  first  store  typing  function  is  defined. 

Proof.  Easily  derived  from  Lemma  15  by  induction  on  the  size  of  U.  □ 

Assignment  only  replaces  values  corresponding  to  the  terminal  leaves  of  a  compound  type.  The  (ai,a2) 
address  pairs  that  express  interior  structure  are  created  once,  by  the  indirection  operator,  and  are  not 
subsequently  changed  by  assignment.  We  already  have  ways  to  name  leaf  values  and  addresses,  using  the 
Leaf  Paths  and  Leaf  Addresses  functions  defined  earlier.  To  prove  soundness  we  also  need  a  way  to  name 
leaf  types.  Auxiliary  function  LeafTypes  in  Figure  19  provides  this  functionality.  All  three  functions  have  a 
similar  recursive-descent  structure;  that  connection  is  formalized  in  the  following  two  lemmas. 

Lemma  17.  A  store  typing  function  is  unchanged  if  augmented  with  the  constituent  leaf  components  of  a 
valid  local  pointer  and  a  type-compatible  value. 

StoreType(m:  S,U  U  {(u,r),  (a,  boxed  local  valid  r)}) 

=  StoreType{m1  S,  U  U  {(u,  r),  (a,  boxed  local  valid  r)}  U  {(szq,  ti),  . . . ,  ( svn ,  Tra)} 

U  {(ai,  boxed  local  valid  Ti), . . . ,  (an,  boxed  local  valid  rn)}) 
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where 


LeafP aths(v)  =  {p1  ■  sv±, . . .  ,p„  ■  svn} 

LeafAddresses(S,  (to,  a})  =  {pi  ■  (m,ai), . . .  ,pn  ■  (m,an)} 

LeafTypes(r )  =  {pi  ■  n, . . .  ,pn  ■  rn} 

provided  that  the  first  store  typing  function  is  defined. 

Proof.  The  proof  is  by  induction  on  the  structure  of  r. 

Base  Case:  Non-Pairs  Suppose  that  r  is  not  a  pair  type.  Then 

LeafPaths(v)  =  {(}  •  v} 

LeafAddresses(S,  (m,a))  =  {()  •  (m,  a)} 

LeafTypesfr )  =  {()  •  r} 

So  in  this  case,  n  =  1  and  pi  =  ()  and  sv i  =  v  and  a\  =  a  and  t\  =  r.  Then  quite  trivially, 

StoreType(m ,  S,U  U  {{v,  r),  (a,  boxed  local  valid  r)}) 

=  StoreType(m,  S,U  U  {( v ,  r),  (a,  boxed  local  valid  r)}  U  {(u,  r),  (a,  boxed  local  valid  r)}) 

=  StoreType(m ,  S,  U  U  {( v ,  r),  (a,  boxed  local  valid  r)}  U  {(sui,  Ti)}  U  {(ai,  boxed  local  valid  n)}) 

Inductive  Case:  Pairs  Suppose  that  r  is  (■ t',t ")  for  some  r'  and  t" .  Then  if  the  first  store  typing 
function  is  defined,  it  must  be  the  case  that  v  is  (v',v")  for  some  v'  and  v" .  Similarly,  S((m,a})  must  be 
(a\  a”)  for  some  a'  and  a”.  Therefore, 

LeafPaths(v)  =  (J  -LeafPaths(v'))  U  (V  ■  LeafP aths(v")) 

Leaf Address es(S,  (in,  a})  =  (/  ■LeafAddresses(S,{m,a')))  U  (\  -Leaf  Address es(S,(m,  a1'))) 

LeafTypes(r)  =  (J  -LeafTypesir'))  U  (V  -LeafTypes(r")) 

Now,  we  know  inductively  that 

LeafP aths(v')  =  {pi  ■  sVj, . . .  ,pj  ■  sVj} 

LeafAddresses{S ,  (to,  a'))  =  {pi  •  (to,  ai),  ■  ■  ■  ,Pj  •  (to,  a^)} 

LeafTypes{r')  =  {pi  •  n, . . .  ,Pj  ■  r,} 

and  that 

LeafP aths(v")  =  {pj+1  ■  svj+1, . . .  ,pn  ■  svn} 

LeafAddresses(S,  (m,a'))  =  {Pj+\  ■  (m,  «j+i),  •  ■  •  ,pn  ■  (m,  an)} 

LeafTypesir")  =  {pj+1  ■  rj+1, . . .  ,p„  ■  rn} 
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for  some  j  such  that  0  <  j  <  n.  Using  these  substitutions, 

StoreType{m,  S,U  U  {((t/,  v"),  (r7,  t")),  (a,  boxed  local  valid  (t7,t77))}) 

=  Xx.  _L  [( TO,  a }  <—  definition  of  StoreType 

U  StoreType(m,  S,U  U  {(i/,  t'),  (a7,  boxed  local  valid  r7)}) 

U  StoreType(m,  S,  U  U  {(i/7,  r "),  (a'1 ,  boxed  local  valid  r77)}) 

=  Xx.  _L  [(m,a)  <—  (t7,t77)]  by  induction,  twice 

U  StoreType(m,  S,  U  U  {(v7,  r7),  (a7,  boxed  local  valid  r7)} 

U  {  (SV\  ,  Ti ),...,  (sVj  ,  7j  )  } 

U  {(ai,  boxed  local  valid  n), . . . ,  ( dj ,  boxed  local  valid  Tj)}) 

U  StoreType(m,  S,U  U  {(u77,  r77),  (a77,  boxed  local  valid  r77)} 

U  {(sui+i,rj+i), . . . ,  ( SVn,Tn )} 

U  {(aj+i,  boxed  local  valid  Tj+1), . . . ,  (an,  boxed  local  valid  r„)}) 

=  Xx.  _L  [(m,a)  <—  (t7,t77)]  regrouping  of  terms 

U  StoreType(m,  S,  U  U  { (x/ ,  r7),  (v",  r77)} 

U  {(a7, boxed  local  valid  r7),  (a77, boxed  local  valid  t77)} 

U  {(sui,ti),  . . . ,  (. svn,rn }} 

U  {(ai,  boxed  local  valid  n), . . . ,  (an,  boxed  local  valid  r„)}) 

=  StoreType(m,  S,U  U  {((u7,  v”),  (r7,  r77)),  (a,  boxed  local  valid  (t7,t77))}  definition  of  StoreType 

U  {(sui,ri),  .  .  .  ,  (svn,  Tn}} 

U  {(«i,  boxed  local  valid  Ti), . . . ,  (an,  boxed  local  valid  rn}}) 

□ 


Lemma  18.  A  store  typing  function  is  unchanged  if  augmented  with  the  constituent  leaf  components  of  a 
valid  global  pointer  and  a  type-compatible  value. 

StoreType(m,  S,U  U  {(v,t),  ({m1 ,  a),  boxed  global  valid  r)}) 

=  StoreType(m ,  S,U  U  {(u,  r),  ((to7,  a),  boxed  global  valid  r)}  U  {(sui,  ti),  . . . ,  (svn,  r„)} 

U  {((to7,  a\),  boxed  global  valid  t\),  . . . ,  ((to7,  an),  boxed  global  valid  r„)}) 

where 


LeafPaths(v )  =  {pi  ■  sv\, . . .  ,pn  ■  svn} 

Leaf  Address  es(S ,  (to7,  a))  =  {pi  •  (to7,  ai), . . .  ,pn  ■  (m' ,  a„)} 

LeafTypes(r)  =  {pi  ■  n, . . .  ,pn  ■  rn} 

provided  that  the  first  store  typing  function  is  defined. 

Proof.  The  proof  is  by  induction  on  the  structure  of  r. 


Base  Case:  Non-Pairs  Suppose  that  r  is  not  a  pair  type.  Then 

LeafPaths{v)  =  {()  •  u} 

LeafAddresses(S,  (to7 ,  a))  =  {()-(TO7,a)} 

LeafTypes(r )  =  {()  •  r} 

So  in  this  case,  n  =  1  and  pi  =  ()  and  =  v  and  ai  =  a  and  n  =  r.  Then  quite  trivially, 

StoreType(m,  S,U  U  {(u,  r),  ((to7,  a),  boxed  global  valid  r)}) 

=  StoreType(m,  S,U  U  {(stq,  ti)}  U  {((to7,  ai),  boxed  global  valid  n)}) 


43 


Inductive  Case:  Pairs  Suppose  that  r  is  ( t',t ")  for  some  t'  and  t" .  Then  if  the  first  store  typing 
function  is  defined,  it  must  be  the  case  that  v  is  (v',v")  for  some  v '  and  v” .  Similarly,  S((m',a})  must  be 
(a',  a ")  for  some  a '  and  a" .  Therefore, 

LeafPaths(v )  =  (/  -LeafPaths(v'))  U  (\  -LeafPaths{v")) 

LeafAddresses(S,  (m1 ,  a))  =  (/  -LeafAddresses(S,  (m!  ,a')))  U  (\  -LeafAddresses(S,  (m' ,  a"))) 

LeafTypes(r)  =  (/  • LeafTypes (t1))  U  (\  -LeafTypesij")) 

Now,  we  know  inductively  that 

LeafPaths(v')  =  {pi  ■  svj, . . .  ,pj  ■  svj} 

LeafAddresses(S,  (m! ,  a'))  =  {pi  ■  (m! ,  ai),  ■  ■  ■  ,Pj  ■  (in' ,  aj)} 

LeafTypes{r')  =  {pi  •  n, . . .  ,Pj  ■  tj} 

and  that 

LeafP aths{v")  =  {pJ+1  ■  svJ+1, . . .  ,pn  ■  svn} 

LeafAddresses(S,  {m! ,a"))  =  {pj+i  •  (m' ,  aj+i), . . .  ,pn  ■  (m' ,  an)} 

LeafTypes{r ”)  =  {pj+i  ■  Tj+1, . . .  ,pn  ■  t„} 

for  some  j  such  that  0  <  j  <  n.  Using  these  substitutions, 

StoreType(m ,  S,  U  U  {{(v' ,  v"),  (t  ,  t")),  ({m1 ,  a),  boxed  global  valid  ( t T,,}}}) 

=  Xx.  _L  [(m',a)  <—  definition  of  StoreType 

U  StoreType(m,  S,U  U  {(?/,  t'),  {(m! ,  a),  boxed  global  valid  r,)j) 

U  StoreType(m,  S,  U  U  {(i/\  r"),  ((m' ,  a”), boxed  global  valid  t")}) 

=  Xx.  _L  [(m1  ,a)  <—  (t',t")]  by  induction,  twice 

U  StoreType(m,  S,U  U  {(?/,  t'),  {(m' ,  a),  boxed  global  valid  r')} 

U  {(swi,  n), . . . ,  (sVj,Tj)} 

U  {((m' ,  ai) ,  boxed  global  valid  n), . . . ,  ((m' ,  aj),  boxed  global  valid  r,)}) 

U  StoreType(m,  S,U  U  {(i/\  r"),  ((m^  a”), boxed  global  valid  t")} 

U  {(svj+i,  rj+ 1), . . . ,  (svn,  r„}} 

U  {({m' ,  Cj+i),  boxed  global  valid  Tj+i), ,  ({m' ,  an) ■  boxed  global  valid  Tn}}) 

=  Xx.  _L  {(m',a)  <—  (t',t")]  regrouping  of  terms 

U  StoreType(m,  S,  U  U  {(U,  r),  {v" ,  t")} 

U  {((m' ,  a),  boxed  global  valid  r),  ((m' ,  a"),  boxed  global  valid  r”}} 

U  {(svi,  n), . . . ,  (, svn,T„ )} 

U  {{{m! ,  a\) ,  boxed  global  valid  n), . . . ,  ((m' ,  an),  boxed  global  valid  t„}}) 

=  StoreType(m,  S,  U  U  {((?/,  v"),  (r  ,  t")),  {{m! ,  a),  boxed  global  valid  (t',t"))}  definition  of  Store  Type 

U  {(sUl,Tl),  .  .  .  ,  ( SVn,Tn }} 

U  {{(m' ,  ai),  boxed  global  valid  n), . . . ,  ({m' ,  an),  boxed  global  valid  rn}}) 

□ 


A. 3. 2  Lemmas  Relating  Consistency  to  Store  Typing 

Lemma  19.  A  store  is  consistent  for  a  single  value  and  type  if  and  only  if  the  corresponding  store  typing 
function  is  defined: 

Consistent{m,  S,  (v,t))  <£=>  StoreType{m,  S,  (v,t))  is  defined 

Proof.  The  proof  is  by  induction  on  the  structure  of  r. 
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Base  Case:  Integers  Suppose  r  is  int.  Then 

Consistent(m ,  S,  ( v ,  int)) 
v  =  i  for  some  integer  i 
StoreType(m,  S,  (v,  int))  is  defined 

Base  Case:  Invalid  Pointers  Suppose  that  r  is  boxed  local  invalid  t'  for  some  t' .  Then 

Consistent(m,  S,  (v,  boxed  local  invalid  t)) 

<==>■  v  =  a  for  some  local  address  a 

•t=f>  StoreType(m,  S,  (v,  boxed  local  invalid  t'))  is  defined 
The  case  for  invalid  global  pointers  is  analogous. 

Inductive  Case:  Valid  Pointers  to  Non-Pairs  Suppose  that  r  is  boxed  local  valid  t'  for  some  t' , 
and  that  t'  is  not  a  pair  type.  Then 

Consistent^,  S,  (v,  boxed  local  valid  r')) 
v  =  a  for  some  local  address  a  A  Consistent(m ,  S,  (S((m,  a)),r')) 

*£=>  v  =  a  for  some  local  address  a  A  StoreType(m ,  S,  {S((m,  a)),  r))  is  defined  by  induction 

StoreType(m,  S,  (v,  boxed  local  valid  t'))  is  defined 

The  case  for  valid  global  pointers  is  similar.  Suppose  that  r  is  boxed  global  valid  t'  for  some  t' ,  and 
that  t'  is  not  a  pair  type.  Then 


Consistent^ ,  S,  (v,  boxed  global  valid  r')) 
v  =  ( m',a )  for  some  m!  and  a  A  Consistent(m' ,  S,  (S((m'  ,a)),r)) 
v  =  (m',a)  for  some  m!  and  a  A  StoreType(m' ,  S,  a}),  t'))  is  defined 

StoreType(m,  S,  (v,  boxed  global  valid  t'))  is  defined 


by  induction 


Inductive  Case:  Valid  Pointers  to  Pairs  Suppose  that  r  is  boxed  local  valid  (ti,T2)  for  some  pair 
of  types  Ti  and  12.  Then 


definition  of  Consistent 


Consistent(m,  S,  (v,  boxed  local  valid  (ti,T2))) 
v  =  a  for  some  local  address  a 
A  S((m,a ))  =  (01,02)  for  some  focal  addresses  01  and  02 
A  Consistent(m,  S,  (oi ,  boxed  local  valid  n)) 

A  Consistent(m.,  S,  (a 2,  boxed  local  valid  72)) 

4=>  v  =  a  for  some  local  address  a 

A  S((m,a})  =  (01,02)  for  some  focal  addresses  01  and  02 
A  StoreType(m,  S,  (a±,  boxed  local  valid  t\))  is  defined 
A  StoreType(m,  S,  (02,  boxed  local  valid  T2))  is  defined 
4=^  StoreType{in1  S,  (v,  boxed  local  valid  (11,72)))  is  defined  definition  of  StoreType 

The  case  for  valid  global  pointers  is  similar.  Suppose  that  r  is  boxed  global  valid  (n,  T2)  for  some  pair 


by  induction,  twice 
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of  types  7~i  and  r2.  Then 


Consistent(m,  S,  (v,  boxed  global  valid  (ti,t2))) 
v  =  (m! ,  a)  for  some  machine  m  and  local  address  a 
A  S((m',a})  =  (ai,a2)  for  some  local  addresses  ai  and  a2 
A  Consistent{m,  S,  {{m! ,  ai),  boxed  global  valid  ti)) 

A  Consistent{m,  S,  {{w! ,  a2),  boxed  global  valid  r2)) 

■u  =  (nr7,  a)  for  some  machine  m!  and  local  address  a 
A  S((m',a))  =  (ai,a2)  for  some  local  addresses  a\  and  a2 
A  StoreType(m,  S,  ((m1 ,  af) ,  boxed  global  valid  ti))  is  defined 
A  StoreType{m,  S,  ((m' ,  a2) ,  boxed  global  valid  r2))  is  defined 
StoreType(m,  S,  (v,  boxed  global  valid  (ti,t2)))  is  defined 


definition  of  Consistent 


by  induction,  twice 


definition  of  StoreType 


Inductive  Case:  Pairs  Suppose  that  r  is  (ti  ,t2)  for  some  pair  of  types  t\  and  r2.  Then 

Consistent(m,  S,  ( v ,  (ti,  t2))) 
v  =  (01,02)  for  some  wi  and  i>2 
A  Consistent{m,  S,  (v\,  Ti)) 

A  Consistent(m,  S,  (v2,  t2)) 
w  =  (td,f2)  for  some  Ui  and  t>2 
A  StoreType(m,  S,  (vi,Ti))  is  defined 
A  StoreType(m,  S,  (V2,  r2})  is  defined 
StoreType(rn,  S,  ((v\,  V2),  {t\,  t2)))  is  defined 


by  induction,  twice 


□ 


Corollary  20.  A  store  is  consistent  for  a  set  of  values  and  types  if  and  only  if  the  corresponding  store  typing 
function  is  well  defined: 


Consistent(m,  S,U)  Store Type(m,  S,  U)  is  defined 

Proof.  Easily  derived  from  Lemma  19  by  induction  on  the  size  of  U. 


□ 


A. 4  Main  Soundness  Theorem 

Theorem  1.  Let  A  h  e  :  t.  Assume  that  m  is  a  machine,  S  is  a  store,  and  E  is  an  environment  such 
that  dom(E )  =  dom(A).  If  initially 


Uniform(StoreType(m,  S,  E  m  A)) 


then 


m,S,E  b  e  — >  v,  S' 

A  Consistentfm,  S' ,  (E  m  A)  U  {(w,  r)}) 

i.e.,  computation  succeeds  and  ends  in  a  state  where  all  values  have  types  consistent  with  the  store. 

Theorem  1  is  too  weak  to  be  proven  directly.  We  instead  prove  the  following  theorem,  which  by  Lemma  19 
implies  Theorem  1. 
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Theorem  2.  Let  A  h  e  :  r.  Assume  that  m  is  a  machine,  S  is  a  store,  and  E  is  an  environment  such 
that  dom(E)  =  dom(A).  If  initially 

Uniform(StoreType(m,  S,  E  N  A)) 


then 


m ,  S,E  b  e  — >  v,  S' 

A  Uniform(StoreType(m,  S',  (E  n  A)  U  {(u,  r)})) 
Proof.  The  proof  is  by  induction  on  the  typing  derivation  for  e. 


A. 4.1  Integers 

Assume  the  last  step  in  the  type  derivation  is 

Ah*:  int 

Then  e  is  the  integer  i.  It  follows  trivially  that  m,S,E  b  i  —>  i,S. 

Given  the  theorem  premise 

Uniform(StoreType(m,  S,  E  m  A)) 

we  conclude  from  Lemma  1  that 

Uniform(StoreType(m ,  S ,  {E  ix  A)  U  {(*,  int)})) 


A. 4. 2  Variables 

Let  the  last  step  of  the  type  derivation  be  an  application  of  the  variable  assumption  rule.  Then  e  is  a  variable 
x.  The  typing  proof  for  x  is 

A(x)  =  T 
A  b  x  :  t 

Because  A  and  E  have  identical  domains,  E{x)  is  defined  and  therefore 

m,S,E  b  x^E(x),S 

From  the  definition  of  the  “m”  operator  we  know  that  (E(x),A(x))  £  E  m  A,  and  therefore  that 
{E  m  A)  U  {(^(x)^)}  =  (E  n  A)  U  {(E(x),  A(a:))}  =  E  m  A.  From  the  induction  hypothesis  it  directly 
follows  that 


Uniform(StoreType(m ,  S,  (E  n  A)  U  {(E(x),  r)})) 


A. 4. 3  Subtyping 

Let  the  last  step  of  the  type  derivation  be  an  application  of  the  subtyping  rule.  The  proof  has  the  form 

A  b  e  :  r  r  <  t' 

A  b  e  :  t' 

By  the  induction  hypothesis,  we  have 


m,  S,E  b  e  — >  v,  S' 

A  Uniform(StoreType(m,  S',  (E  x  A)  U  {(u,  r)})) 


Then  Uniform{StoreType{m ,  S' ,  (£  N  A)  U  {(u,  r7)}))  follows  from  Lemma  6. 
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A. 4. 4  Indirection 


Let  the  last  step  of  the  type  derivation  be  an  application  of  the  rule  for  f  e' .  The  type  derivation  has  the 
form 

A  h  e  :  r 

A  \~  1  e  :  boxed  local  valid  r 

By  the  induction  hypothesis  we  have  that  m,So,E  b  e  — >  v,  Si.  The  premises  of  the  operational 
semantics  rule  for  |  are: 

to,  Sq,  E  b  e  — »  v,  Si 

Paths(v)  =  {pi, . . .  ,Pi,Pi+ 1  •  s^+1,  ■  •  •  ,Pn  ■  sw}  where  pi  =  () 
newn{m,  Si)  =  {ai, . . .  ,an} 

svi  =  ( a,-,  a*, )  where  p»-  /=  pj  and  p*-  \=  pk,  for  1  <  i  <1 
S2  =  Si[(m,a i)  «-  siq,.. . ,  (m,an)  <-  si;„] 

We  have  already  shown  the  first  line  by  induction;  the  remaining  premises  simply  define  names  for 
addresses  and  store  values.  We  may  conclude  that 

m,S0,E  b  |e— >ai,S2 

Now,  5*2  simply  extends  S±  at  a  set  of  fresh  locations.  By  Corollary  5  we  know  that  fresh  extension  does 
not  change  store  typing  functions.  Thus,  since  we  have  Uniform(StoreType(m,  Si,  (E  x  A)  U  {(i>,t)}))  by 
induction,  it  must  also  be  the  case  that  Uniform(StoreType(m,  S2,  (E  x  A)  U  {(v,  t)})). 

It  remains  to  show  that  the  new  pointer  ai  to  the  root  of  v  is  uniform  in  S2  as  well.  The  proof  is  by 
induction  on  the  structure  of  r. 

Base  Case:  Non-Pairs  Suppose  that  r  is  not  a  pair  type.  Then  v  must  be  a  suit  ably- typed  integer  or 
pointer,  and  S2  =  Si[(m,ai)  <—  v]. 

Now,  from  the  definition  of  new  we  know  that  (to,  ai)  is  not  in  the  domain  of  Si,  and  so  StoreType(m ,  Si,(E  m 
A)  U  {(t;,  t)})((to,  ai))  =_L..  Then  StoreType(m,  S2,(E  m  A)  U  {(c,  t)})((to,  ai))  =_L  as  well,  since  these  two 
store  typing  functions  are  equivalent  by  Corollary  5.  Thus,  extending  the  latter  store  typing  function  to  be 
r  at  (to,  ai)  preserves  uniformity.  Hence, 

Uniform(StoreType(m,  S2,  (£«i)U  {(r>,  r)})) 

==>  Uniform(StoreType(m,  S2,  (£«i)U  { (v,  v) })  U  Xx.  J_  [(to,  ai)  <—  r]) 

==>  Uniform(StoreType(m,  S2,  (E  m  A)  U  {(S2({m,  ai}),  r)})  U  Xx.  _L  [(to,  ai)  <—  r]) 

=>  Uniform{StoreType{m,  S2,  (E  n  A)  U  {(ai,  boxed  local  valid  r)})) 

Inductive  Case:  Pairs  Suppose  that  r  is  (ti,t2)  for  some  ri  and  r2.  Then  v  is  (vi,v2)  for  some  Vi 

and  v2.  Also,  S3  =  S2[(m,ai)  <—  (02,03),  •  •  ■]  for  some  a2  and  03  such  that  p2  =  (J)  and  P3  =  (\)  in  the 

operational  semantics. 

Now,  from  the  definition  of  new  we  know  that  (to,  at)  is  not  in  the  domain  of  Si  for  any  1  <  i  <  n.  Thus, 
StoreType{m,  Si,{E  x  A)  U  {(v,  t)})((to,  Oj))  =_L.  Then  StoreType(m,  S2,  (E  n  A)  U  {(v,  r)})((m,  o,))  =_L 
as  well,  since  these  two  store  typing  functions  are  equivalent  by  Corollary  5.  Thus,  extending  the  latter  store 
typing  function  to  be  (ti,t2)  at  (to, ai)  preserves  uniformity.  Hence, 
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Uniform(StoreType(m,  S2,  (E  m  A)  U  {((vi,v2),  (ti,t2))})) 

=>  Uniform(StoreType(m,  S2,  (E  n  A)  U  {((vi,v2),  (ti,t2))}) 

U  At.  ±  [(m,a i)  <—  (ri,r2)]) 

•<=>■  Uniform(StoreType(m,  S2,  (E  n  A)  U  {(ui,ti),  (v2 ,t2)}) 

U  At.  ±  [(m,ai)  <—  (ri,r2)]) 

=>  Uniform(StoreType(m,  S2,(E  M  A)  by  induction,  twice 

U{(a2,  boxed  local  valid  Ti),  (03,  boxed  local  valid  r2)}) 

U  A.t.  ±  [(to,  ai)  <-  (ti,t2)]) 

=>  Uniform(StoreType(m,  S2l  (E  n  A)  U  {(ai,  boxed  local  valid  (ri,r2))})) 

A. 4. 5  Dereferencing 

Let  the  last  step  of  the  type  derivation  be  an  application  of  one  of  the  rules  for  [  e! .  There  are  two  cases. 

Local  Pointers  Assume  the  type  rule  applied  is 

A  b  e!  :  boxed  local  valid  r 

A  h  l  e'  :  t 

By  induction  we  have  that 

m,So,E  b  e1  — >  a,  S± 

A  Uniform(StoreType(m,  S 1,  (E  n  A)  U  {(a,  boxed  local  valid  r)})) 

From  the  operational  rules  for  [  it  follows  that 

m,So,E  h  J,  e'  — >  Value{S\1{m,a)),S\ 

Corollary  13  then  ensures  that  Uniform{StoreType(m,  Si,  (£«yt)U  {( Value(S\,  (to,  a)),  })t))  holds. 


Global  Pointers  For  the  second  case  assume  the  type  rule  applied  is 

A  be7:  boxed  global  valid  r 

A  b  j.  e'  :  expander) 

By  induction  we  have  that 

m,S0lE  b  e'  — ►  g,Si 

A  Uniform(StoreType(m,  S\,  (E  m  A)  U  {(g,  boxed  global  valid  r)})) 

From  the  operational  rules  for  J.  it  follows  that 

to,  So,  E  b  l  e'  — >  WideValue{S\,g),Si 

Corollary  16  then  ensures  that  Uniform(StoreType(m,  Si,  (E  m  A)  U  (Wide  Value(Si,  g),  expand(r ))))  holds. 


A. 4. 6  Function  Application 

Let  the  last  step  of  the  type  derivation  be  an  use  of  the  function  application  rule.  The  type  derivation  has 
the  form 

A(f)  =  int  — >  int  Abe:  int 
A  b  /  e  :  int 
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By  induction  we  have  that 


m,S,E  b  e'  — >  i,  Si 

The  premises  of  the  operational  semantics  rule  for  function  application  are: 

to, *5*0, E  b  e'—>i,Si 
E(f)  =  <j)  €  Fun 
=  i! 

We  have  already  shown  the  first  line.  Because  A  and  E  have  identical  domains,  the  second  and  third 
lines  follow  as  well,  so  we  know  that 

m,  So,  E  b  fe->i',Si 


By  induction  we  have  that 

Uniform(StoreType(m ,  Si,  (E  M  A)  U  {(*,  int)})) 
From  Lemma  1  we  conclude  that 


Uniform(StoreType(m,  Si,  (E  M  A)  U  {(*',  int)})) 


A. 4. 7  Assignment 

Let  the  last  step  of  the  type  derivation  be  an  application  of  the  assignment  rule.  There  are  two  cases. 


Local  Assignment  For  the  first  case,  assume  the  type  rule  applied  is 

A  b  ei  :  boxed  local  valid  r 
A  b  e2  :  t 
A  b  ei  :  =  e2  :  r 

By  induction  we  have  that 


m,So,E  b  ei  — >  a,  Si 
A  m,Si,E  b  e2  — ►  v,  S2 

These  satisfy  the  first  two  premises  of  the  operational  semantics  rule.  As  an  indirect  consequence  of  Lemma  17 
we  know  that  LeafPaths{v)  and  LeafAddresses(S2,  (to,  a))  produce  sets  of  the  same  size  and  with  pairwise 
matched  paths.  Thus,  the  third  and  fourth  premises  of  the  operational  semantics  hold  as  well: 


LeafAddresses(S2,  (to,  a))  =  {p±  ■  (to,  ai), . . .  ,pn  •  (to,  an)} 

A  LeafPaths(v )  =  {p\  ■  sv  1, . . .  ,p„.  •  svn} 

Finally,  observe  that  the  definition  of  the  indirection  operator  (})  for  pairs  guarantees  that  all  addresses  are 
unique.  Thus  Oj  ^  a,j  if  i  ^  j,  which  ensures  that  the  simultaneous  update  expressed  by  the  final  operational 
semantics  premise  is  well  defined: 

S3  =  52  [(to,  ai)  <-  sv  1, . . . ,  (to,  an)  <-  svn ] 

Having  satisfied  all  premises  of  the  operational  semantics,  we  conclude  that  assignment  “works” ,  produc¬ 
ing  a  result  and  an  updated  store  as  defined  by  the  applicable  semantic  rule: 

m,S0,E  b  ei  :  =  e2  — >  v,  S3 

We  demonstrate  uniformity  in  two  stages.  By  induction  we  know  that  the  left  hand  side  pointer  a  is 
uniform  in  Si.  We  first  show  that  it  remains  uniform  in  S2,  after  the  right  hand  side  has  been  evaluated. 
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We  then  show  that  the  right  hand  side  value  v,  which  is  inductively  uniform  in  S2,  remains  uniform  in  S3 
after  all  substitutions  have  been  performed. 

We  begin  with  the  left  hand  side.  Let  y  be  a  fresh  variable  not  occurring  in  the  domain  of  E  or  A.  Clearly 

StoreType(m,  Si,  (E  m  A)  U  {(a,  boxed  local  valid  r)}) 

=  StoreType(m ,  Si,  E[y  <—  a]  m  E[y  <—  boxed  local  valid  r]) 

We  know  that  m,S\,E  b  e2  — >  v,S2-  Since  y  does  not  appear  in  either  E  or  A,  and  therefore  cannot 
appear  in  e2,  we  also  have  m,Si,E[y  «—  a]  b  e2  — >  v,S2-  Applying  the  induction  hypothesis  we  conclude 
that 


Uniform(StoreType(m,  S2,  ( E[y  <—  a]  M  E[y  <—  boxed  local  valid  r])  U  {(1;,  t)})) 
from  which  we  immediately  get  that 

Uniform(StoreType(m,  S2,  {E  n  A)  U  {(v,  r),  (a,  boxed  local  valid  r)})) 

Thus,  we  know  that  the  pointer  on  the  left  hand  side  remains  uniform  even  after  the  right  hand  side  has 
been  evaluated. 

We  must  now  show  that  the  right  hand  side  remains  uniform  following  the  substitutions  that  produce 
store  S3.  By  Lemma  17  we  can  flatten  out  any  compound  pair  structure  in  v  and  a,  yielding 

Uniform(StoreType(m ,  S 2,  (E  m  A)  U  {(v,  r),  (a,  boxed  local  valid  r)} 

U{(sv1,r1),...,(svn,Tn)} 

U  {(asi,  boxed  local  valid  T\), . . . ,  (an,  boxed  local  valid  r„)})) 

where  svi  and  at  are  given  above  by  the  operational  semantics,  and  LeafTypes(r)  =  {pi  ■  T\, ...  ,pn  ■  rn}. 
Then  by  Corollary  8  we  have 

Uniform(StoreType(m,  S3,  (E  m  A)  U  {(v,t),  (a,  boxed  local  valid  r)} 

U  {(sui,  ti),  . . . ,  (svn,  Tn)} 

U  {(ai,  boxed  local  valid  T\), . . . ,  (an,  boxed  local  valid  r„)})) 


from  which  we  readily  conclude 

Uniform(StoreType(m,  S3,  (E  m  A)  U  {(v,  r),  (a,  boxed  local  valid  r)})) 

Global  Assignment  For  the  second  case,  assume  the  type  rule  applied  is 

A  b  ei  :  boxed  global  valid  r 

A  b  e2  :  t  robust(r) 

A  b  ei  :  =  e2  :  r 


By  induction  we  have  that 


m,  So,  E  b  ei  -»  g,Si 
A  m,S\,E  b  e2—>v,S2 

These  satisfy  the  first  two  premises  of  the  operational  semantics  rule.  As  an  indirect  consequence  of  Lemma  18 
we  know  that  LeafPaths{v )  and  LeafAddresses(S2,  g )  produce  sets  of  the  same  size  and  with  pairwise  matched 
paths.  Thus,  the  third  and  fourth  premises  of  the  operational  semantics  hold  as  well: 

LeafAddresses{S2 ,  (m,  a ))  =  {pi  •  gi, . . .  ,pn  ■  gn} 

A  LeafPaths(v)  =  {p±  ■  sv  1, . . .  ,pn  ■  svn} 
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Finally,  observe  that  the  definition  of  the  indirection  operator  (f)  for  pairs  guarantees  that  all  addresses  are 
unique.  Thus  g,  7^  gj  if  i  ^  j,  which  ensures  that  the  simultaneous  update  expressed  by  the  final  operational 
semantics  premise  is  well  defined: 

S3  =  S2[gi  <-  sv  1, ...,gn<-  su„] 

Having  satisfied  all  premises  of  the  operational  semantics,  we  conclude  that  assignment  “works” ,  produc¬ 
ing  a  result  and  an  updated  store  as  defined  by  the  applicable  semantic  rule: 

m,S0,E  b  ei  :  =  e2  — >  v,  S3 

We  demonstrate  uniformity  in  two  stages.  By  induction  we  know  that  the  left  hand  side  pointer  a  is 
uniform  in  Si-  We  first  show  that  it  remains  uniform  in  S2,  after  the  right  hand  side  has  been  evaluated. 
We  then  show  that  the  right  hand  side  value  v,  which  is  inductively  uniform  in  S2,  remains  uniform  in  S3 
after  all  substitutions  have  been  performed. 

We  begin  with  the  left  hand  side.  Let  y  be  a  fresh  variable  not  occurring  in  the  domain  of  E  or  A.  Clearly 

StoreType(m,  Si,  (E  m  A)  U  {(a,  boxed  global  valid  r)}) 

=  StoreType(m,  Si,  E[y  <—  g\  m  E[y  <—  boxed  global  valid  r]) 

We  know  that  m,S\,E  b  e2  —■ ►  v,S2.  Since  y  does  not  appear  in  either  E  or  A,  and  therefore  cannot 
appear  in  e2,  we  also  have  m,Si,E[y  <—  g\  b  e2  — >  v,S2.  Applying  the  induction  hypothesis  we  conclude 
that 


Uniform(StoreType(m.,  S2,  ( E[y  <—  g\  n  E[y  <—  boxed  global  valid  r])  U  {(u,  r)})) 
from  which  we  immediately  get  that 

Uniform(StoreType(m ,  S2,  (E  x  A)  U  {(v,  r),  (a,  boxed  global  valid  r)})) 

Thus,  we  know  that  the  pointer  on  the  left  hand  side  remains  uniform  even  after  the  right  hand  side  has 
been  evaluated. 

We  must  now  show  that  the  right  hand  side  remains  uniform  following  the  substitutions  that  produce 
store  S3.  By  Lemma  18  we  can  flatten  out  any  compound  pair  structure  in  v  and  a,  yielding 

Uniform(StoreType(m. ,  S2,  (E  N  A)  U  {(v,  r),  (g,  boxed  global  valid  r)} 

U  {  (sVi ,  Ti )  ,  .  .  .  ,  {sVn,Tn)} 

U  {(51,  boxed  global  valid  Ti), . . . ,  (gn,  boxed  global  valid  r„)})) 

where  SVi  and  gi  are  given  above  by  the  operational  semantics,  and  LeafTypes(r)  =  {pi  ■  n, . . .  ,p„  ■  rn}.  The 
type  rule  requires  that  robust(r)  hold.  By  a  simple  induction  it  must  be  the  case  that  all  robust.^ )  hold  as 
well.  Then  by  Corollary  11  we  have 

Uniform(StoreType(m,  S3,  (E  m  A)  U  {(v,  r),  (g,  boxed  global  valid  r)} 

U  {  (SVi ,  Ti )  ,  .  .  .  ,  {sVn,Tn)} 

U  {(51,  boxed  global  valid  T\), . . . ,  (gn,  boxed  global  valid  r„)})) 


from  which  we  readily  conclude 

Uniform(StoreType(m,  S3,  {E  N  A)  U  {{v,t),  (g,  boxed  global  valid  r)})) 

A. 4. 8  Sequencing 

Let  the  last  step  of  the  type  derivation  be  an  application  of  the  sequencing  rule.  The  type  derivation  has 
the  form 

A  b  e\  :  ri  A  b  e2  :  t2 
A  b  ei  ;  e2  :  t2 
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By  induction  we  have  that 


m,So,E  b  e± —+ Vi ,S\ 

A  m,S\,E  b  e2—>v2,S2 

A  Uniform(StoreType(m, Si,  (E  m  A)  U  {(vi,ti)})) 
A  Uniform(StoreType(m,  S2,  {E  m  A)  U  {(i^t^)})) 

It  follows  from  the  operational  semantics  that 

E,m,S0  b  ei  ;  e2  — >  v2,  S2 

and  the  induction  hypothesis  directly  shows  that 

Uniform(StoreType(m.,  S2,(E  M  A)  U  {(v2,  r2)})) 


A. 4. 9  Pair  Construction 

Let  the  last  step  of  the  type  derivation  be  an  application  of  the  pair  construction  rule.  The  type  derivation 
has  the  form 

A  b  ei  :  ri  A  h  e2  :  t2 
A  b  (ei,e2)  :  (ri,r2) 

By  induction  we  know  that 

m,So,E  b  ei  — » ,S\ 

A  Uniform(StoreType(m,  Si,  (fixyt)U  { <vi ,  Ti) })) 

Our  strategy  here  is  similar  to  that  used  in  part  of  the  soundness  case  for  assignments.  Let  y  be  a  fresh 
variable  not  occurring  in  the  domain  of  E  or  A.  Now  we  have  that 

StoreType(m,  Si,  (E  m  A)  U  {(14,  ri)}) 

=  StoreType(m,  S\,  E[y  <—  v{\  N  A[y  <—  ri]) 

We  know  that  m,Si,E  b  e2  —>  v2,  S2 .  Since  y  does  not  appear  in  either  E  or  A,  and  therefore  cannot 
appear  in  e2,  we  also  have  to,  S\,E[y  <—  ui]  b  e2  — »  v2,  S2.  Applying  the  induction  hypothesis  we  conclude 
that 


Uniform(StoreType(in,  S2,  ( E[y  t>i]  N  A[y  <—  n])  U  {{v2,  r2}})) 

from  which  we  immediately  get  that 

to,  So,  E  b  (ei,e2)  — >  (v1,v2),S2 

A  Unijorm(StoreType{m,  S2,  ( E[y  <—  Ui]  M  A[y  <—  ri])  U  {(u2,  t2}})) 

Now 


Uniform(StoreType(m. ,  S2,  ( E[y  <—  Ui]  N  A[y  <—  n])  U  {(v2,  r2}})) 
Uniform(StoreType(m,  S2,  (E  n  A)  U  {(ui,  n),  (v2,  r2)})) 

Uniform(StoreType(m,  S2,  (E  n  A)  U  {((wi,  v2),  (n,  r2))})) 

which  proves  the  result. 

A. 4. 10  Pair  Selection 

Let  the  last  step  of  the  type  derivation  be  an  application  of  the  pair  selection  rule.  There  are  several  similar 
cases. 
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Local  Valid  Pointers  Assume  that  the  type  derivation  has  the  form 

A  he':  boxed  local  valid  (ti,T2) 

A  h  @1  e'  :  boxed  local  valid  7q 

By  induction  we  have  that 

m,So,E  h  e'  — >  a,  Si 

A  Uniform(StoreType(m,  Si,  (E  N  A)  U  {(a,  boxed  local  valid  (ti,T2)}})) 

The  applicable  operational  semantics  rule  requires  that  we  show  the  following: 

m,So,E  h  e/ — >  a,  Si 
A  Si((m,a))  =  (ai,a2) 

The  first  premise  holds  by  induction.  The  second  premise  follows  directly  from  the  definition  of  StoreType 
for  local  pointers  to  pairs.  Now, 

Store Type(m,  Si,  (a,  boxed  local  valid  (ti,72))) 

=  Xx.  4-  [(m,a)  <—  (ti ,  t2)]  definition  of  StoreType 

U  Store Typeim,  Si,  (cq,  boxed  local  valid  n)) 

U  Store Type(m,  Si,  (a2,  boxed  local  valid  r2)) 

□  StoreTypeim,  S\,  (cq,  boxed  local  valid  n)) 

from  which  uniformity  directly  follows.  The  case  for  @2  is  analogous. 

Global  Valid  Pointers  Assume  that  the  type  derivation  has  the  form 

A  be7:  boxed  global  valid  (iq,  r2) 

A  b  Ole7  :  boxed  global  valid  iq 

By  induction  we  have  that 

m,So,E  h  e1 (m' ,a),  Si 

A  Uniform(StoreType(m,  Si,  (E  M  A)  U  {((m',  a),  boxed  global  valid  (ti,t2))})) 

The  applicable  operational  semantics  rule  requires  that  we  show  the  following: 

m,So,E  b  e'^(m',a),Si 
A  Si((m',a))  =  (ai,a2) 

The  first  premise  holds  by  induction.  The  second  premise  follows  directly  from  the  definition  of  StoreType 
for  global  pointers  to  pairs.  Now, 

St  ore  Type(m,  Si,  ({m' ,  a),  boxed  global  valid  (ti,t2))) 

=  Xx.  T  [( m! ,  a )  <—  (ti,t2)]  definition  of  StoreType 

U  Store Type(m.,  Si,  ({m! ,  aq),  boxed  global  valid  Tq)) 

U  Store Type(m.,  Si,  ((in',  a2),  boxed  global  valid  r2)) 

□  Store Type(m,  Si,  ((mf,  ai),  boxed  global  valid  iq)) 

from  which  uniformity  directly  follows.  The  case  for  @2  is  analogous. 

□ 
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